Everybody is a great coder

It's now over fifteen years since I first got money for a program that I wrote, and since over ten years I consider myself a professional software engineer. When I started out programming I was convinced that raw coding ability and deep, innate technical knowledge of a few programming languages would be all it would take to make it in the industry. But over the years I learned that there is more to being a professional programmer than hacking together complex code. Having worked both in academics and industry, this often became most apparent to me when working with newbies fresh out of college. Often they are great programmers, but lack some of the surrounding skills to make them look professional to me. So what distinguishes the common coder and/or hobbyist from the pros? Before I forget: This article is written on a purely subjective basis of my personal experiences, feel free to tell me that I'm wrong

Diversify your knowledge

Get things done with your code

While being an able coder is not the only thing that counts, not being one immediately disqualifies you to become a successful programmer. Be sure to master at least one full fledged, common programming language such as C#, Java, C++ etc. Go into details of the language, know the standard libraries, know how to wield the language to great effectiveness and know how to cope with any limitations it will have. As a bonus to your main language, know at least one scripting language to automate small tasks, create quick experiments and do ugly proof-of-concepts. Don't be slowed down because you don't know your basic tool - the programming language - well enough.

In short: Make sure you know how to get things done and get them done reliably.

Show me your mind

Getting complex things to work is only one side of the medal, the other side is that those complex structures want to be explained. Maybe your fellow code monkeys want to discuss a problem with you, maybe it's your boss trying to get a grip with your skills, maybe it's plain old documentation that needs to be written. Whatever the cause, sometimes just writing code comments is not enough. Know how to visualize (and read) software structures. Be it UML diagrams, flow charts, ERD or simply venn diagrams, know how to draw a diagram that others can understand. You don't need to be fully proficient in the last details of the "official" iconographics of any visual language, but not being able to draw a simple class diagram or state machine will leave your thoughts behind closed doors for others. On the other hand, learn to recognize (and name) patterns in these charts, however badly scribbled by one of your fellow hackers.

Prove me that it works

Yay, your great ideas and concepts are approved by your team and you've written that beautiful piece of code to solve the problems of the world. But does it survive the impact of the users? Testing, Testing, Testing is the only answer to this. Know how to test and debug your program. Relying on print-debugging and testing by "it appears to run correctly" may work for small projects and in the short-term, but there is a certain point where we want to guarantee that a program works in exactly 'that' way. While you don't need to embrace test-driven development in the full, know at least about unit testing, know how to use a debugger efficiently, use software asserts and read into design by contract. Learn how to do a performance analysis of your code and other non-functional requirements. Be able to write consistent and good tests for your software, know what is covered by your tests and what is not.

Your code has a history

While well-tested code is a must, sometimes the path that lead to any particular solution is also important. Sometimes you just have to see how code evolved to understand it or find the exact moment when a bug was introduced, luckily there are plenty of versioning tools out there which help with this task. Be sure to know about source code management and versioning systems. It doesn't matter whether this is SVN, Git, Mercurial, TFS or any of the others on the market, just be at home with the usage of at least one and get the basic concepts behind them. It's not just about versioning, but also about backing up code and tracability of features. It's astounding how many hours of productivity I've seen go down the drain because some guy in a team of coders just did not use versioning software properly. Be it in files lost, because of an acciential overwrite, being unable to merge a conflict with a team member or just messing up the workflow for everybody else by not following the basic concepts behind source code management.

Take one for the team

Now you're able to produce well-designed, peer-reviewed, tested and traceable code which greatly increases your chances to be seen as a professional software engineer. Time to start working together with other great professionals out there. Software development is no longer an occupation for loners who work alone, nowadays software development is considered a team sport by many successful companies. So be sure that you are prepared to work together with other humans and become a teamplayer. Grasp the basic fundamentals of software development processes in teams, know about iterative vs. incremental software development, about defining deliverables and features. There are tons of development processes out there to read into, be it scrum, kanban, XP, feature driven development - whatever floats your (or your employer's) boat. No need (yet) to get any certificate on anything about these processes, but be aware that they exist, and that they are used to great success by many software producing companies. Another major point is if you want to be part of a tight-knit development team, learn to be a "good citizen" for that team. Be honest towards yourself and others, learn how to communicate on a professional level if things don't go according to your plan and last but not least, sometimes you just have to bite the bullet, swallow your pride and take one for the team.

That's it?

Am I missing something in this article? Certainly.

Of course there is more to being a successful programmer/software engineer than the five points mentioned above, and of course not all of them apply to the same extent to anyone or any company. Working with a startup-indie studio that needs to produce something now with limited personal resources puts a different weight on things than being hired by an AAA company were you are just a tiny cogwheel in a great machine.

Also some of the things mentioned above are easy to learn, while others need time and experience to grow. Learning tools is easy, learning people is hard. It's a catch-22 you need to work together with other professionals to gain the skills needed to be accepted as a professional yourself. Keep an open mind for well meant critiques and be reflective about yourself and don't give up.

Feel free to comment on this article or reach me over PM.

Article Update Log

No updates yet