Don't code in bad environments

Looking back on my 19 years as a developer with some very long stints in positions, I can say this with some certainty: If you want to remain relevant as a developer, you either have the autonomy to completely change how you do things, or you should be practicing interview questions. Unfortunately I didn’t know this at the time, so I learned the hard way: awkward interviews and many hours re-skilling.

Why autonomy is so important

One of the core responsibilities of a software developer is to solve problems in the best possible way. In software, the best way frequenty changes. If you aren’t free to change how you do things, it means you aren’t free to do your job.

Positions which don’t offer autonomy have you solving problems the rest of the world has moved on from years ago. If the application is important enough to substantially change, then it’s important enough to be on technology that allows coding in a reasonable way. In open source, where developers have autonomy, you see some repos continue to be updated and others become “as is”.

It’s not all about the code

If your company is dictating your development process then they are very slightly removed from telling you what to name a function. This also extends to working hours and whether the office is mandatory. You need the flexibility to work the way you do best, or you’re hobbling yourself right from the start.

Let’s talk about product management in bad environments. The best case is that engineers help propose new work but engineering must at least be able to push back on PM and CTO ideas. If any one person’s suggestions are unquestioned there will be a lot of useless coding. Not being useful to customers then feeds back into it not mattering if the developer environment is reasonable.

How to get autonomy if you don’t have it

Leave. Find a new position that offers it and be sure to ask the questions in David’s code factory blog to make sure they offer it.

If you stay you will need a side project but that’s not a quick fix:

• A side project for money is conservatively a 50 / 50 engineering marketing split.
• Skew towards front end work - back end projects tend to require big data sets or large amounts of traffic that are hard to come by without funding. Also quality of UI is easier for customers to quickly judge.
• If you work on a side project by yourself it will be harder to achieve the complexity necessary to keep technical skills and impossible to work on collaborative skills.

Don’t wait too long

I know what you are probably thinking because I thought it every day for years - “I need to get more autonomy - I’ll start on that next week.” Don’t play yourself. Here’s a link to the latest employment numbers for new graduates. At the time of this writing almost a quarter of new graduates are under or un-employed.

The only thing really separating you from their ranks is the ROI you bring to the table and there is a clock ticking on your abilities.

How to provide freedom to change if you are in charge

This isn’t the “I heard typescript was cool so let’s re-write everything” sort of change. Getting a team of developers to agree on anything isn’t easy. So if the team says we need X to do our jobs, you should listen.

But without your team even saying anything you should take a look at your process. Are you forcing meetings on developers? Does your process really include continuous improvement or just endlessly carry forward a wish list that’s never fulfilled?