Being a professional programmer
In this article I will tell you about my story of becoming the professional programmer. I have been programmer for 9 years now. For the most of that period I was not the professional one. Not that I did not work in companies for money (which could be the definition of being professional in some way), but I was not acting like one.
What is a professional?
Being professional is when someone has aims and qualities that characterize his profession. In software/web development the main aim should be to produce good products and quality in this case represents being able to use best practices to do so.
Why did I not do that?
My aim, at the beginning, was always to satisfy my bosses, which meant to produce products that only appear to have quality. The main reason for that was that the features had to be pushed in production “yesterday”. However, underneath the surface, code that was powering the product was not maintainable at all. As a result, bugs in production were a common thing.
As you can tell, not only that my aim was wrong, my qualities were also a big problem. The reason for that was that I have just started my career and I did not know the better way to deal with this issue. I thought that was the way that all companies and teams were working accordingly. Sales department comes with a big new client that would be the next big step for the company, only if we could push this set of features in 7 days. Working on weekends and after-hour were a common thing and we would all gladly do it.
That was 9 years ago. What saddens me is that this “Startup Culture” is a new standard for all new companies that are trying to push their new products to public. The more experienced developers that I was back then are doing the same mistakes I did. It is expected of you to do what I have just described. Eventually, we came to the point of this post. If this is the standard now, then how could we be the professionals.
Honestly speaking, it is very hard. It is impossible to push features with this tempo and write meaningful code.
Being professional means that sometimes you should stand up and fight. Communication here is the key. You need to communicate about all the problems, with this approach, with your bosses and product owners. In doing so, the person could expect one of two possible outcomes. The first one could be that they listen to you and agree to work on a problem together, because you are playing for the same team at the end. The second outcome could be that they could dismiss you and sometimes even fire you if you keep consistently raise that question to them.
If latter is the case, that could very well be blessing in disguise. By that I mean, who really wants to work for company like that. Right?
Well, let us go back to my beginnings again. At that period I was working at the only company that would hire me at that time. And the pay was good. So, yeah, I, nine years ago, would want to work at that company. We need to be honest that financial security is a big motivator.
Being ethical is another quality real professional should have. If company had been doing something that you thought was wrong and not only in development practices, but also in other areas, like deliberately coning its customers, no matter how good the pay had been, right and professional thing to do would have been to quit if you could not have changed that.
And just like writing code that is bad and not maintainable, writing a product that will do harm to your customers on purpose is not what a real professional would do. Is that something that you really wanted to continue doing on daily basis?
Bill Sourour talks about this in his famous blog post The code I’m still ashamed of. If you didn’t read it by now, you definitely should.
We are the part of the problem
The company problems are not always an issue. Programmers themselves are also the problem. A lot of times in my career I felt too lazy to do the right things even if I had time and could easily do it. Result of that was the same as above. Uncle Bob talks about this in his book a lot. You have to have pride of code you write. If you do not have pride, then you are not doing it right.
If you submit a program to a QA team, and they get back to you with 20 bugs, that means you did lazy, half-arse work. I am not talking about misinterpreting features given by the product owners or project managers here, I am talking about plain bugs. I was in this situation more then once. If you continuously do this, ask yourself what is the problem!? Why don’t you have motivation to do better job? Is the project boring? Is the job boring?
Something is definitely wrong. No matter how bad the development process is, this amount of bugs means that developers are not doing their job as they should.
Taking responsibility for a bug is also a part of being professional. But think how silly you would look if you would continuously took responsibility for those 20 bugs each time you submit an app to QA team for evaluation.
If you practice a peer-review system, submitting a code that is bad and untested will lower your reputation within your colleagues. Do you want that?
So next time you write a code that is eventually going to production, think hard, is it worth it, not to give 100%? Is it worth it to create a code that you are not proud of?
Programming is a profession like any other. Would you have courage to cross the bridge that was made by architect or engineer who did not put 100% of themselves when she/ he had designed it? A bridge that she/he was not proud of ? I think not.
I changed my ways, I encourage You to do the same!
About the Author
30 year old software developer from Mostar, Bosnia and Herzegovina, currently living and working in Frankfurt am Main, Germany.