What Do I think of “Full Stack” Development and the DevOps Movement?

Once again, I’m doing reader question Monday on a Tuesday.  I have no good excuses this time, either.  We arrived last week in San Diego, which is beautiful.  So, I’ll just flat out admit that I spent the weekend strolling beaches, eating lobster tacos, drinking craft beers, looking up at the stars and just generally enjoying life in a way that involved no writing of blog posts.  I regret nothing.

So let’s to reader question Monday on a Tuesday.  This is actually a question that just came in today as I was gearing up to write about TDD and remote teams.  It caught my attention, so I’ll give about the fastest turnaround time I’ve ever done on a question.

I recently stumbled upon this article: https://jeffknupp.com/blog/2014/04/15/how-devops-is-killing-the-developer/

Which seems to lump Full-Stack dev in with DevOps, and discards DevOps, on the premise that the full-stack dev is good-for-the-org-bad-for-the-dev. I know you’ve weighed in against the full-stack dev with preference for specialization. I wonder if you believe this also means DevOps is DOE, or if there’s still room for DevOps in your mind (or perhaps more broadly speaking, for startup-like, feature-teams so often found in Agile/Scrum orgs)?

If you don’t like DevOps, what do you recommend instead to manage the entire release automation process, and everything else it entails?

Alright.  There’s a lot for me to work through here, so let’s break things up a little.

DevOps (And Full Stack) is Killing “The Developer?”

First, let me recap briefly the article’s thesis.  And I’m really going to try to be gentle here and non-objectionable.  I trade in blog posts for a living these days, and slugging it out with random people on the internet has worn as thin as it can possibly wear to me.  I’d really rather not argue with this Jeff Knupp, and I can certainly empathize with waging a vigorous campaign to make your own job more fun.

The article’s thesis is, essentially, this, from the perspective of a salaried employee in the enterprise.

I hate the DevOps (and full stack) movements because I like writing code and they result in me writing less code.

The author might object to this thesis, but that’s really the message.  It asserts the superiority of the software developer as compared to other individual contributor roles, and then argues that DevOps and full stack (and forced skill diversification in general) are good for the employer, but bad for the employee.  (Although he then curiously argues that it’s also bad for the employer, since they’re “overpaying” for non-development labor.)

Read More

A Career Guide for the Recovering Software Generalist

Since I’m kind of an old man, in college, they taught me C and its shiny new cousin, C++.

This was a CS program, so they didn’t ultimately focus on the language.  Instead, they went on to focus on the theory of things: algorithms, data structures, reasoning, and, well, computer science.  But they had to teach us just enough language for us to make sense of and apply those concepts.

So C/C++ it was.

My first full time programming job was a dream come true for the software generalist.  They had C and C++ both for me to work on.

But they had plenty of other language besides, and not a ton of manpower to spare.  So I learned Visual Basic.  And also PHP.  Oh, and Java.  (There were actually a few other things besides, but I think you get the point).

By the time I was about 4 years into the workforce, I’d switched my focus as the world moved toward web apps.

I’d gone from working on Linux kernel programming in C to Java web apps with Spring and Ant.  Fast forward several years, and I’d switched it up heavily again.

Java web apps?  Pff, that was so 2006.

I went to work for a completely different company, making a completely different product, and became a C#/WPF developer of desktop applications.

I was the consummate software generalist.

The Software Generalist Source of Pride

I was proud of this, too.  If you’d asked me what I specialized in, I’d have said something like this.

My specialty is that I’m a generalist.  I live and breathe code.  Don’t care about your domain or your particulars and I don’t care about your language or stack.  I’ll be good anywhere, as long as it’s code.

If you’d pressed me on the specialty point, I might have conceded a little.

Well, I guess my specialty is object oriented programming.  Yep, if you need inheritance, encapsulation or polymorphism, I’m your man!

These days, assuming you read this blog with any regularity, you probably know how ruefully I tell this story.

• I’ve written how free agents can stop generalizing and about the idea of niching down.
• I’ve given advice for free agents to specialize.

But today I’d like to double down on this advice by offering it to salaried folks and not just freelancers.  You should specialize.

Read More

Resume Skills for the Job Seeker with Upward Ambition

It strikes me that, lately, I write a lot about how to make it in a free agent world (or how to get there).  So today, I’d like to switch up it a little and give a nod to those of you in the salaried world, and perfectly happy there to boot.

But don’t expect me to talk about a resume skills section or what have you without at least a little realpolitik and a little cynicism.

The resume-interview one-two punch is a stupid way for employers to find employees.  Full stop.  But it’s also the prohibitive incumbent and the system that you’re going to have to navigate.

So let’s focus on resume skills today and give you a fighting chance at navigating the process.  In fact, let’s go beyond just navigating it and look at how to maximize how it works for you.  This has two essential components.

• Filter the riff-raff employers out of your search as quickly as possible.
• Impress the ones you care about.

Let’s look at how you can tune the resume skills section to help with both.

The Anatomy and Purpose of a Resume

First of all, let’s consider the purpose of a resume.  Lansing Community College, winner of the SEO sweepstakes for “what’s the purpose of a resume” has the following to say.

The purpose of a resume is to provide a summary of your skills, abilities and accomplishments. It is a quick advertisement of who you are. It is a “snapshot” of you with the intent of capturing and emphasizing interests and secure you an interview.

Who am I to argue with an institution of higher education?

That all sounds exactly like the ostensible purpose of a resume and a very sunny assessment besides.  It’s your own tiny commercial in print, and, done right, it gets you interviews.

But let’s be a little more blunt about the way things work.

You put together a resume, trying to stuff as many self-aggrandizing tidbits as you can in there while looking plausibly humble.  Then you fire it off for the viewing displeasure of an extremely bored person whose main mission is to find reasons not to call you.

This resume filtration will feature two passes, usually.  These include an automated or semi-automated pass to disqualify anyone without the magic acronyms and a second one to disqualify anyone that seems fishy somehow.

To navigate this minefield, you put together a resume with the following sections.

• Basic contact information.
• Employment history, including job titles, job descriptions, and accomplishments.
• Education.
• The resume skills section.
• Some people include an “objective” which should probably be “straight cash, Homie.”  (Just kidding — no one appreciates honesty here, so I’d just omit this altogether)

What do Resume Skills Look Like?

In this particular post, though, I’m going to focus on the resume skills, so let’s not worry about the other sections too much.  The standard advice there is usually good, particularly the part about trying to quantify the accomplishments at your various jobs as much as possible.

It’s the resume skills section that features the great tragedy among the broader, lesser tragedy that is this whole process.  I’m talking about this, lifted from a hypothetical resume for one Amy Jones, “midlevel software engineer,” on Monster.com (hey, they’re still truckin’, apparently!).

Read More

Conference Speaking Isn’t Good for Your Career Until You Make it Good

I like watching developer talks, live and recorded.  For my money (or free, depending on the venue), it doesn’t get any better than listening to Bob Martin work his way into a talk on software design by talking first about astronomy.

He and so many other speakers are engaging, charismatic, and informative.

So we strive to be like them.  We should put our names out there, give talks, and build our brand.

The Benefits of Conference Speaking

“Build our brand” is a little wishy-washy, though, so let’s get specific.  How does speaking at conferences help you?  I have my own opinion on this, but I went out in search of others’ to see.  In broad strokes, here are some specific things that I saw.

• Make yourself better at public speaking.  It’s like Toastmasters, but in your domain.
• Speaking at conferences means attending conferences, and that helps you “network.”
• Give back.  Do your part in advancement of the general cause of programming knowledge.
• Teaching something is a great way to learn, so speaking at conferences forces you to up your game and improve your chops.

I found some blog posts on the subject offering specifics.  Scott Davis says, “the knowledge that I’ve gained from teaching workshops has been invaluable and I don’t believe that I would have been as successful with out it.”  Heidi Waterhouse says, among other things, “I also do it because I want to show up and be technical and expert and pink-haired in the world.”

That last statement, in particular, I think summarizes up the common speaker experience in the development world (though Heidi, herself, is apparently not a software developer, per se.)  Public speaking on a topic helps you acquire a lot of skills associated with speaking publicly about that topic.  And it helps you “show up in the world.”

What’s less clear is how, exactly, that benefits you in your career.

Getting Specific about Your Career and the Benefits

Now let me say something up front.  If you’re speaking at conferences for the love of the game or to generally become a better rounded person, then what I’m telling in the rest of the post will either be passive food for thought or else not entirely applicable.  For the rest of this post, I’m addressing people who are speaking at conferences to help their careers, with the idea of offering advice on how to make it help your career much more efficiently.

When listening to people tout the career benefits of conference speaking for software developers, it generally takes on this iconic form.

1. Speak at conferences.
2. ….
3. Profit!

I mean, it doesn’t actually go that way.  People don’t actually say, verbatim, “you should speak at conferences and then stuff happens and then your career takes off!”  Instead, they just say that speaking at conferences is good for your career.

How so?  Well, it “builds your brand.”  Okay.  And what does “building your brand” do for you as a senior software engineer or a freelance app dev pro?  Ah, well, it’s about marketing yourself!  Better job opportunities.  Advancement.  You know, … profit!

But let’s look at what, exactly, we’re saying will arise out of conference speaking.  And also what, exactly, people put into it.

Read More

Remote Programming Jobs: How to Find Them and Why You Should

I’m going to take a break from my aggressive war on status quo wage programming jobs today.  Instead, I’ll offer something a little more how-to-y and a little more upbeat.  And I won’t once try to talk you out of salaried employment.  Instead, I’ll try to talk you into it.  Or, at least into a kind of it.  Let’s talk remote programming jobs.

Some, But Not Too Many, Words of Caution

I am, personally, an introvert.  So I always find the cautionary tales around remote work to be pretty overblown.  They go something like this.

Remote work seems like it’d be great.  And, for the first few weeks, it is!  But then you start to get lonely and stir crazy.  Before you know it, you’re heading down to Starbucks for a human connection just content to have some teenagers giggle at you.  And the weight gain?  You’re working right by your fridge!  And not to mention… [blah, blah, blah]

And it devolves from there.  I always read these posts and think of the song, Space Oddity.  You’d think these people were loading themselves into a tiny capsule and blasting off for the Kuiper Belt alone, never to see another human.

Look, if you’re really a group-oriented person, an extrovert, or someone who strongly prefers collaborative work, you may struggle working from home.  But then, if you’re that sort of person, you’re probably not reading this post.

If, on the other hand, you like working alone, don’t let these obligatory cautionary tales scare you.  I’ve been working mostly remotely for years and totally remotely, non-stop for 8 months, mostly in a very small town.  And I’ve never yet felt the need to hug a random barista to slake a bone-deep loneliness.

You still have friends, right?  Family?  A phone?  You’ll be fine.

Things to Guard Against

Okay, so we’ve established that you probably won’t morph into a much needier person than you’ve ever been.  But there some things around which you need to take care.

Bear in mind that these are not deal breakers, nor are they insurmountable.  They’re just things that you need to manage, especially at first, until you settle into a rhythm.

• If you’re not used to imposing structure and discipline on yourself in terms of time management, you might need to learn this.  Maintain a schedule, set a todo list, and that sort of thing.
• On the flip side, some people in remote situations go too far the other way and start to work all the time.  Set boundaries.
• Depending on your work situation, you might need to get used to showcasing your contributions.  This holds doubly true if you’re in the minority as a remote worker.  Find a way to keep your boss posted on what you’re doing and your teammates engaged.
• Remote doesn’t necessarily (or even ideally) mean that you never have facetime.  Expect to travel for meatspace interactions from time to time.

After a few weeks, you’ll settle in and find what makes sense for you, perhaps tweaking from time to time.  Just make sure to keep an eye out over the duration of your tenure as a remote worker for things that you can do to improve your productivity and interactions.

Why Remote Programming Jobs?

Alright, now that we’ve gotten the cautionary stuff out of the way, let’s move on to why you would want this.  I’ll cite my own experience, in list format, talking about the benefits.

• Not commuting gives you back up to 2 hours per day.
• You can work remotely from anywhere.  This year, I’ve worked from a lake in the woods, big cities, and now that it’s gotten cold up north, a house right next to the Gulf of Mexico.  You can vagabond or visit family.
• Assuming you’re not a big time group collaborator, you’ll get work done much more productively without regular interruptions and distractions.
• Wearing whatever is comfortable is a nice lifestyle perk.
• Programming and similar knowledge work pursuits are deep work, which means some isolation lets you immerse yourself more in them.
• You have a much more flexible schedule to accommodate family life or various schedule restrictions you might have.

I’ve talked about cautions, but I can’t overstate how great a lifestyle this is, provided you’re comfortable with limited professional face time.  Your life takes on a sort of freedom and autonomy that’s hard to replicate when you spend your days in an office.

But I won’t sell any further.  Let’s look at how to get yourself into a remote situation.

Read More