How should a software developer measure their success?
When I was younger and starting out in my professional software development career, I used to think it was how much code I sling.
Like Clint Eastwood in “A Fistful of Dollars”, I liked to pretend I was a cyberspace cowboy, a code monkey with no name who would drift into town, understand the requirements for a new software project, and spend all day pounding away on my keyboard like I was a digital gunslinger, until the project was complete.
It didn’t help that my manager at the time pretty much had the same philosophy about software development productivity. He didn’t consider our team of software developers productive unless he heard the pounding of fingers on keyboards.
Heck, if my manager thought productivity meant more code, who was I to argue?
That is, until the people I supported and were the customers I needed to keep happy, started using the applications I wrote.
And they found and reported lots and lots of bugs and defects in my code. I ended up fixing lots of mistakes and design flaws, which I’m sure had a lot to do with the fact I was so green and was just starting my journey as an apprentice computer programmer.
But more importantly I think, I was missing the point about what a software programmer actually is supposed to do.
As weird as it may sound, a computer programmer’s job isn’t to write code.
Computer code is merely the expression and embodiment of what you want a computer to do.
Until computers learn to think for themselves and become artificially intelligent, computers are about as smart as a sack of hammers. They excel at performing tasks far faster than any human could ever possibly imagine.
But they still need the instructions (computer source code) from a human, in order to do something.
Furthermore, it needs to be the RIGHT kind of human instructions. A computer has no idea, nor cares whether the computer code fed into it by a human software developer, will actually solve the actual problem it is supposed to solve.
It took me the longest time to learn this first principle of what makes a developer successful.
A Software Programmer Solves Problems
To be even more precise, a software programmer knows how to solve the RIGHT problem.
That’s what kept tripping me up in the early days of my professional software programming career.
I was so eager to get down to coding, I didn’t spend the time to truly understand the problem I was supposed to be solving with my computer code.
If you don’t truly understand the nature of the business problem you are trying to solve, it won’t matter what kind of programming language, framework, database, whiz-bang new methodology like lean, or any other technical tool you have at your disposal.
If enough time, research and analysis isn’t put into designing a proper foundation for a house or a building, it won’t matter what kind of building materials and manpower you put into building everything on top of the foundation.
If the foundation is faulty, the whole structure is faulty and doesn’t have any chance of success.
In much the same way, if a software developer doesn’t spend enough time truly understanding a business problem, no amount of technology is going to be able to solve the problem.
A successful software developer is one who recognizes this is one of the most crucial aspects about software development.
They won’t rush to the keyboard and start slinging out code the minute they get a project assignment.
They talk with the people who know the most about the business problem they are trying to solve and ask lots of questions about the nature of the problem. How the current business process works.
There’s this phrase that fans of agile and scrum development methodology are fond of saying. “Analysis Paralysis”. It’s the premise that spending too much time research and analyzing project requirements is futile and actually counterproductive.
Agile and Scrum has proven success with many companies and organization, but it’s certainly not perfect and not without its flaws.
The notion that you can spend too much time in the analysis phase of a project and not enough time actually developing your solution is a bunch of hooey to me.
Ok, MAYBE it does exist. But nine times out of ten, every software project I have been on that has ended up in failure or costly delays, is because not enough time was spent understanding what the business problem actually was.
Hey, nobody (at least that I know of) enjoys spending long and laborious meetings in an analysis phase of a project.
But the end result has always paid off.
Once a software developer understands the business problem, then they can start thinking about the technical solution and the code that will be needed to solve it.
A Good Software Developer Knows How to Learn
A good software developer knows that learning is probably the most important tool in their technical toolbox.
Technology changes so fast, and it’s only speeding up.
A good software developer doesn’t get attached to any particular software tool, programming language, framework, database or development methodology. All these things are fleeting.
The ones that do end up as legacy programmers. They may be valued for their unique knowledge that fewer developers know about, and it might benefit them in the short term.
During the Y2K crisis, many banks and financial institutions realized that tons of their old mainframe-based COBOL source code used 2 digits for years instead of 4 and would cause lots of bad repercussions unless something was done about it.
If you were a veteran COBOL mainframe programmer at the time, and you knew how to fix Y2K problems for a bank, you would have been handsomely rewarded for it, and for many legacy COBOL programmers, it ended up being a nice and profitable windfall.
But sooner or later, there just won’t be enough demand for COBOL programmers. And those legacy software developers who refused to learn new technologies and methodologies will find themselves between a rock and a hard place.
Sadly, the same thing happened to a team of legacy software programmers I briefly worked with.
Their skills were deemed no longer necessary and the company decided to let them go with severances. Many of them were still shocked that the company would do something like that. They may have thought their jobs were secure.
They either refused to believe or were unwilling to take the time and effort to learn new skills.
Learning how to learn new things is one of the best ways to future-proof a software developer’s skills.
Good Developers Work Well with Others
I have been on both sides of the technical job interview table for software developer positions.
And regardless of whatever side of the interview table I was sitting on, the one quality that determined whether a developer would get hired or not hired for a position was the quality of “team fit”.
That is, how well did the interviewers think the job candidate would work within a team environment, which is how most software development environments take place.
I’ve even learned that I was personally selected for a technical software developer position over someone else with more technical experience and knowledge, because I was told I seemed like a person who worked well with others and was eager to work in a team-based environment.
Which is true. I don’t like working as a “lone wolf developer”. I like being able to work in a team environment where I can bounce ideas off other software developers and get important feedback.
That doesn’t mean one always has to go with the flow of the team. If you truly believe a team is heading in a wrong direction, a good developer should certainly voice their concerns and objections.
You can always teach a software developer how to learn a new technical skill but one thing you can’t do is teach them how not to be unlikeable.
That is something no technical book or programming language, will ever teach.
Good Developers Strive to Write Better Code
Easier said than done, I know.
I’ve been in the programming game for almost twenty years, and I still feel like I’ve just scratched the surface about how to create quality code.
Maybe it helps to understand what IS good code.
Good code is easy to read and understand and easy to change.
To know how to create code that does this is a lifelong journey of learning, trial and error and learning from your own mistakes. And possessing the humility and humbleness to acknowledge that you are not the best programmer in the universe and your code is full of flaws and mistakes.
What kind of person likes to admit that? Of course, we all like to think our work is perfect.
The good developer is able to admit there is always room for improvement in the way we write software code.
From time to time, I still make rookie mistakes in my code. I need to keep reminding myself it’s a lifelong journey to write quality code. Nobody said it was going to be easy.
Software design patterns. Design principles. Understanding loosely coupled code and inversion of control. Object oriented programming. Functional programming. The list goes on and on. I could purchase every technical book and online course on the planet for the next ten years and still feel like a novice.
But that’s the fun part about this programming racket. How many other professions are there where every day can be a brand new learning experience?
