Jump to content

Like
19Likes
Dislike
Get Professional - A Professional Skillset for Software Engineers

Peer Reviewed by jbadams, Dave Hunt, mousetail


What distinguishes the common coder and/or hobbyist from the pros?

4: Adsense

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" iconography 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 leads 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 traceability 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 accidental 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 team player. 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 where 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

About the Author(s)

Dominik is your average software developer with a bit of experience and a deep interest in agile development and collaborative teamwork to make better software.

License

GDOL (Gamedev.net Open License)

6 Comments

Jul 27 2015 09:49 AM

Good article, really interesting :D

Jul 27 2015 12:29 PM

Great article overall.

 

Communication is key in any team environment.  I know we are introverts, lone coder, who grew up in remote solitary environments (e.g. parent's basement), but communication is very important.

Aug 10 2015 03:51 PM

Nice article.  I like your ideas.

 

One thing I think I would add to "Take one for the team" point is to open yourself up to advise/constructive criticism.  We programmers can be very shy and protective of our code, because in many respects it represents us, our thought processes, and (possibly) our capabilities.  This can lead us to be either over or under confident of our abilities (typically based on your personality, I find).

 

Share your code.  Get feedback.  Don't be afraid to admit to yourself that there is a better way to do something.  To successfully work in a team, often times you either need to bring yourself up a peg or down a peg.  It will make you a better programmer and the teams you work on more successful.

Aug 13 2015 12:54 AM

One thing I think I would add to "Take one for the team" point is to open yourself up to advise/constructive criticism.  We programmers can be very shy and protective of our code, because in many respects it represents us, our thought processes, and (possibly) our capabilities.  This can lead us to be either over or under confident of our abilities (typically based on your personality, I find).

 

Share your code.  Get feedback.  Don't be afraid to admit to yourself that there is a better way to do something.  To successfully work in a team, often times you either need to bring yourself up a peg or down a peg.  It will make you a better programmer and the teams you work on more successful.

 

Very good advice, for me this plays into becoming a teamplayer and being a "good citizien" for your team. 

Aug 14 2015 08:30 PM

Very good advice. 

 

For many years i have been guilty of some of the shortcomings you mentioned. Though i think that has to do with the fact that my first degrees were in Engineering, while i did some quick Post Grad degrees in CS. 

 

Though I'm able to write complex code but without necessarily using advanced features of the language (Java in this case)

 

 

 

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

 

Having said that, i would like to add that the advice you gave (quote) probably needs to be qualified just a little bit. 

I find out through the years that if one is adventurous and taking risks in the particular project being developed (not just doing mediocre, average, rehashing usual or out of the text book stuff) then not getting certain things done (on time) sometimes doesn't necessarily mean one doesn't know how to get things done

 

Great article! 

Aug 17 2015 01:34 PM

Having said that, i would like to add that the advice you gave (quote) probably needs to be qualified just a little bit. 

I find out through the years that if one is adventurous and taking risks in the particular project being developed (not just doing mediocre, average, rehashing usual or out of the text book stuff) then not getting certain things done (on time) sometimes doesn't necessarily mean one doesn't know how to get things done

 

Great article! 

 

Thanks for the appreciation but I disagree with your statement. While being creative is part of being a programmer and sometimes you have to experiment to find a solution, producing working software is the only thing that counts in the end. Any good working environment should make room for experimenting but I would rather have this not tightly integrated in any project with a deadline.
 

Note: GameDev.net moderates article comments.