Reflecting On 10 Years As a Developer

Intro

It has been roughly ten years since some poor soul decided it was a good idea to pay me to do this thing called software. Since this industry follows the Jem'Hadar rules or aging, this little milestone supposedly makes me an elder. So as a senior citizen of the IT world, why not dole out some thoughts for everyone to ignore at their leisure? Let's yell at some clouds, share some wisdom and put some pen to the paper.

So here's my five "lessons for life in software".

1. There is no work-life balance

If you feel like you need to balance how much you work and how much you live, I fear you have already lost. To your work. So waves a hand all jedi like put aside that death stick, go home and rethink your life. Work is there to facilitate your life. Not the other way around.

Work is there so you can live. You don't live so you can work.

One more time.

Work is not life. Life is not about working.

Work to live. Don't live to work.

2. Best practices are like opinions

And like opinions, they are like assholes: everyone's got one and sooner or later it gets smelly.

The best way to treat any blog post, book or declaration of best practices is to view them as a trend. Trends come and go. Treat best practices not as scripture but a nice offer of principles that might, might, work for you and your team. If it does, good for you. If it doesn't, well you'll form your own eventually and they are as valid as the guru you just read from.

Let me put it this way: You read a blog post about best practices (as one does). Then a year later you read another that says absolutely opposite of what you read a year previous. It might be even from the same author! Are you going to refactor your entire code base to follow this new paradigm because your favorite guru told you so? Hell no (I hope that's your answer). But they are all united in the desire to make work and life easier. So what's a code monkey to do? One word: consistency. That's really what best practices in the end are. Consistent way of doing things. Whatever rules you've got set up, stick to them.

3. Fancy titles look like imposter syndrome

I am a software developer. I am not a "software artisan", "code ninja", "devops master super engineering supreme commander" or my personal pet peeve, a "software engineer".

Maybe I'm in the minority but I am predisposed to be suspicious of all things hype because usually if it sounds too good to be true, it is. The fancier and more pretentious your title sounds, more eagerly I start looking around for the curtain to see what's really going on and on whose face do I have to throw some water.

Call me humble and maybe I am in the minority but it feels arrogant and presumptuous to invent some fancy name to describe what I do when what I do is not really that different or special than what others do. If you feel like you need to invent a new word to describe how awesome you are, odds are you really are not, but are trying to pretend you are. That's called lying by the way.

Now, titles that describe a function of your work like a tester, devops, database admin and so forth are fair game because they serve to inform rather than impress.

As the Bard put it: "This above all: to thine own self be true."

4. And I too feel like one on occasion

The imposter syndrome. Simply put, an idea that you are really not that good at your job and somehow against all odds you have been faking it this entire time. Your boss, your coworkers, your clients. Everyone somehow bought into the hype that is you and chose to give you money for absolutely nothing. Your entire career is a con artists wettest dream come true.

Sound pretentious? Welcome to the paradox friend.

It has been my observation that the panacea for this particular illness is not a pill but two things: time and experience. The more you do, the more you learn and what skills you have get honed further. That doesn't mean you don't get that feeling still on occasion. But you are better equipped at managing it and putting it aside. Because turns out, you are qualified.

5. Curiosity killed the cat. Good thing you are not a cat.

Software is an industry that moves at lightning speed. Almost every branch of this industry constantly changes and evolves. Tools change, new ways are invented to solve problems, abstractions are abound. Sometimes they are better, sometimes they are not.

Imagine if you drove a taxi for a living and every few months you get a new car but the pedals are all different, the shift gear has switched position to the roof and instead of sitting down you are standing up. Or next time you are sitting down but the shift gear is automated. Or let's say you are a plumber and every few months you need to be certified for a new kind of a wrench that promises to double your torque with half the effort.

This is the reality IT and software as an industry is living in. Of course other industries change and evolve as well but in the software world that evolution cycle is much much faster and if you don't watch it, you might get left behind. So if one is to survive, the most important trait in any developer's toolkit is curiosity. The desire to learn new things and at least keep track of industry happenings. Yes that might mean spending a day or two to learn another JavaScript framework (sigh), database or a new fancy code offering but that's the nature of the beast today.

That is unless you are a Cobol developer working for banks. Those skills live forever and you are set for life. Unless a Rust developer comes along...

Anyway, dare to be curious. It will be rewarded.

Outro

So there's some "rules" that I try my best to apply to myself. You might even call them my "best practices" for living and working. Some of them are just observations of phenomenon and how to overcome them. Other's at times even harsh lines that I try not to cross. I hope you find this little post informative, though provoking, and perhaps even entertaining.