Valued work

Monday, 19 August, 2013 — work engineering career

The saddest thing I’ve seen in the last few years of interviewing software engineering candidates is that a fair amount end up in career dead ends. They work for the wrong sort of company, they’re trying to get out and they’re struggling because they’re unprepared to be most anywhere else.

There are two major classes of employer I see this career anti-pattern in. First are places like banks or other large institutions where software is some manner of back office function. The second is the small “cowboy” shop where “there’s no time” for doing things the, “right way.”

What does the anti-pattern look like? There are a few tells:

First, the organization/boss can’t abide anything other than the briefest of manual testing. Unit testing, functional testing, an agile validation and verification effort or a waterfall pass through a separate QA group are all “too much” or unheard of or seen as unnecessary.

Second, the developer is solving the same problem, the same way year after year. Business runs in cycles. At the same time, if this August is the same as August last year and August two or more years ago, watch out. Quite likely, the business is ignoring or simply unaware of something that could be better.

Third, the developer works on their own or with an equally inexperienced coworker. But it’s really not pair programming or XP. It’s just two developers working in separate silos that don’t talk to each other. All of the other engineers may have been around the block a few times, some more than others, but no one has left the neighborhood in years. This ties back to the point above. If no one is seeing anything new, no one has anything new to bring to the team and everyone stagnates together.

Fourth, there are no consistent development practices like code review. Continuous integration is still magic to a lot of folks. Depressingly, source control that everyone on the team uses at all, let alone with a consistent approach, is far from universal, too. No project or prototype is too small for ‘git init’.

There are plenty of other smells, but those four are scary enough to start with.

Now, for the sake of discussion, let’s stipulate that you have a friend about whom you’re concerned because you recognize this friend’s job hits this group of smells and your friend is casting about for a new gig and not getting anywhere.

First, just because writing software for a company or a contract hits one or more of these anti-pattern points doesn’t make them bad people or a bad employer. This is orthogonal to all of that. Jobs are scarce, everyone’s circumstances are different and, as a profession, we’re really, really lucky. That said, what’s going to help keep your friend’s skills relevant? Let’s start with a harsh gate.

Avoid companies that don’t understand what it is your friend does, why they hired your friend and thereby, what your friend’s value to the organization is. A lot of times, your friend will need to talk to others, like their hiring manager, about whether or not the company understands what it is they need. If they don’t, your friend has two options. Try to educate them or find another job. The first option sometimes works, your friend shouldn’t be shy about trying it. Yet, if your friend is months into a gig and it still isn’t clear to everyone what what your friend’s value is, advise your friend to move on.

Avoid companies that don’t support good engineering practices. If this is your friend’s first engineering position, please understand your friend is at a disadvantage for being persuasive about good engineering practices. If your friend knows what good practices are and can’t convince the business to adopt them, your friend should move on.

The key for your friend is finding a gig that values that friend’s craft and the standards and practices of that craft. Software engineering is a diverse field, so it’s quite possible people in different areas of the field are going to have different definitions. But, I’ll assert the following:

• Everyone, individually, needs to be the most passionate advocate for their own career
• Everyone, individually, needs to stay abreast of what is going on in their chosen field
• Everyone, individually, needs to practice the skills that will help get them to where they want to go
• A company, or at worst, a hiring manager, should understand why they are hiring a developer and how that developer’s practices contribute to the value the developer brings to the company.

Further, developers understanding the following things have a definite advantage over developers who do not:

• Pair programming
• Continuous Integration
• The Gang of Four Design Patterns (even if you aren’t working in Java or C)
• Behavior or Test Driven Development
• Software deployment methodologies

This is beyond just having knowledge of languages and algorithms. It’s knowing and understanding how our peer group works.

Now, your friend? What might you tell this friend, in terms of improving their situation? There are two books I recommend starting with to kickstart thinking through software development practices and career development. They are, The Pragmatic Programmer by Dave Thomas and Andy Hunt and The Passionate Programmer by Chad Fowler. They are my go-to “kickstart someone’s career” books.

Above all else, your friend has to value their work and their skills to match well with an employer who respects what they bring to the table and what supports those skills. The same goes for you, too.