I have been writing software that other people have been using now for just over 20 years, and it occurs to me that I really should have some useful advice to impart to other developers who are at the start of their own careers. It is in that frame of mind that I therefore offer the following to the profession, in no specific order:
Be Engaged.
Being the guy who punches in at 9am, leaves a 5pm having done eight hours of the same old stuff is a road to nowhere. We are creative individuals in a rapidly moving profession, surrounded by colleagues of a similar mind. If you are happy to just plod on with the job whilst making no effort to improve yourself, the community will pass you by and your skills will stagnate. So, be engaged in software development, read about it, listen to podcasts about it, run naked through the streets proclaiming your love of it if you must, but don’t just “plod on”.
The truth of the matter is that it doesn’t take a lot of keep abreast of what is going on, as there are no shortage of people shouting about it whichever platform you are working on. Websites abound, quality online training is now available at a reasonable cost to all (Pluralsight, Eggheads etc…), and if all else fails there’s always Youtube…
You are not a God!
We developers tend to see the world in absolutes, and form firm opinions easily. We convince ourselves that our approach is the smartest way of achieving most given tasks (easily done – it is after all the best way we know of) and we are always, at least in our own minds, one step ahead of our colleagues. Newsflash – all of your colleagues have gone through the same thoughts and feelings as well, and we can’t all be right!
Be open to the ideas, approaches and solutions of those around you, Cast a critical eye over their ideas, and if you’re mature enough, an equally critical eye over your own. Discuss strengths and weaknesses, and don’t obsess over having to be recognised as the best developer in the room – you’re not, and neither is anyone else. We all have strengths and weaknesses.
Don’t drink the management kool aid…
Some newcomers believe it’s their job to go along with whatever management wants – and they’re wrong. It’s your job to work together with management toward meeting the goals of your projects. That doesn’t mean agreeing with everything they say, and it certainly doesn’t mean letting them dictate solution designs to you…
In my experience, good managers are like rocking horse shit, because once they’ve climbed the greasy pole they tend to want to throw their weight around. A good manager will limit their role only to helping to ensure the team delivers as promptly and cost-effectively as possible – and in such a role they are an ally! A truly exceptional manager will foster a culture in the team that there are no sacred cows, nothing that is not open for discussion, and no one on the team who is beyond challenge. These managers are rarer still…
Stay away from the developer kool aid as well!
That is not to say that you should ally yourself with other developers rather than managers, but rather that you shouldn’t really be thinking in those terms at all… If you find yourself working in a team where the developers are all allied against the management, then it’s time to ask how that situation has arisen, and what can be done about it. At the end of the day, we’re all supposed to be on the same team and working to common goals, and internal bickering isn’t getting the job done.
A well functioning software team is one where nobody is afraid to raise ideas, flag concerns, or talk to one another. There’s nothing wrong with disagreement – it can be a very healthy thing in terms of considering different ideas. What matters is how disagreements are handled.
Don’t suffer fools – lightly or in any other way…
A few years ago, I worked for a company (I’ll spare their blushes and not name them) who had, and there’s really no other way of saying this, the technical architect from hell. How bad was it? A few quotes from the chap:
- “In all the time I have worked here, we have never employed a developer I actually respect” – spoken in a room filled with eight (fortunately non-violent) developers.
- “Our developers are too stupid to understand branching and merging…” – they were not stupid at all – the problem was that the technical architect didn’t understand it.
- “What does Private mean in C# again?”
Other notable events:
- Calling one of our junior female developers “Sugartits”.
- Banning the use of Entity Framework or any other ORM because “I’ve heard they can be slow.”
- When complaining about me in a meeting with my boss and I, getting so out of control yelling that my tactic (which worked) was to simply sit there quietly until the tirade ended, turn to my manager and ask “Do you see my problem?”.
Enough about this one specific chap – but something to note is how much text I wrote before returning to the general case – years after the event, I still instinctively rail against the guy. Clearly this wasn’t a productive relationship.
The mistake I made was staying in the relationship. The man in my view had some “issues” that I was never going to be able to have an impact on, so his behaviour would not change. I’ve spent entire days dealing with him when I could have been productively writing code instead – elsewhere if needs be.
What this episode did teach me was that such behaviour cannot be tolerated, and allowing it to continue was a mistake. If I’m ever treated like this by someone again in my professional life, I will try to constructively address the issue with them. If I’m unable to do that, I’ll find another job… Life is too short to suffer like this…
Don’t be the idiot.
For this first half of my career, I never encountered a female developer. I even began to wonder if such people existed – women are certainly under represented in IT. When I encountered my first female colleague (Waves at Linda) it came as something of a shock, all the more so being that my last position had been around the very male orientated world of automotive parts supply.
I initially treated Linda as some kind of curiosity – well done you for sticking to your guns and making it in a man’s word, ya big girlie girl!
This was shameful, because Linda was just another developer trying to get the job done, and her gender should have been neither here nor there… I eventually realised what I was doing, how Linda was being treated, and stomped it out – but it took months. For months she had to come into work and deal with the stupid idiot who had a nonsensical issue with something she couldn’t, wouldn’t and shouldn’t change. I was Linda’s idiot.
We soon recovered our working relationship, but through an act of sheer dickery I could have lost Linda, and here’s the thing – I liked her. She actually helped me in my career, because she was always very good at playing devil’s advocate, and wasn’t afraid to tell stupid people when they were being stupid.
In short, if someone has a problem with you, do something about it. DO NOT assume they must be wrong, and try to look on the situation dispassionately.
Variety is the spice of life…
Consider getting involved with an open source project, and seeing how a different collection of developers do things. Of course, there’s no guarantee that the things they are doing are right, or in some cases even sane, but that’s not the point… You will only learn so much from working within one team, and getting involved in something else will expand both your horizons and your thinking…
Personally, I’ve spent years working in environments where everyone with commit rights to the code was sat within 100 yards of my desk. Distributed, open source development works in an entirely different way – you have to think about branching, you have deal will Pull Requests… You have to manage your relationship with others on the project differently, and everyone has to act professionally or nothing gets done.
In my open source work, I have even been heard to utter “You guys really, really need a business analyst here…”. Normally, that would have required electrodes on my testicles before I would begin to contemplate such craziness. Think BAs are a pain in the ass? See what happens when Project Managers work without them!
Software development is an exciting industry, and as with any other industry has it’s share of visionaries, it’s share of “plodders” and it’s share of assholes. As a new software developer, you need to continually challenge yourself in terms of am I being professional?, am I being diligent?, and of course the big one, what can I do better?