At my job I have had the unique opportunity to be involved in the hiring process of new software engineers. Where I work, after the initial interview you have a series of second interviews with a subset of the developers. There are three of us that give these second interviews. The first two are senior developers that have been developing with (and outside) the company for some time, and then there is me, who has been a developer for 1 and 2/3 years (plus my internship before hand). I think my role in the interview process is to give a “newbie” perspective of the company to the candidates.
In the past few weeks we have had a rush of interviews (almost one every day!), and a few of them have asked me for advice on prepping for the job, what things they might want to learn, and what they may expect to learn (or should learn) after some time working as a SE.
In the first year as a developer I think there are a few things I can already see as worthwhile advice for new software developers, I implore the senior software developers out there to please let me know if anything I say is not right.
Advice 0: Identify and understand that you (and most software developers) suck at coding. That’s right, we are horribly bad at it. I have seen people come in (and I am by no means devoid of this problem) with the belief that the code they write is God’s gift to the world. It is the holy sacrament, a beast worthy of Tolkien, the code that could run the USS Enterprise… no… it is crap. We’re too error prone to create code that is any good on our own. The key there is “on our own”. Recognizing we are horrible coders is the first step to becoming great coders. If you embrace this you will open yourself to a world of good practices, including ego-less programming and successful code reviews. Furthermore, your humbleness will help you to work well in teams. Nobody wants to work with that guy (or gal) who can’t accept criticism.
Advice 1: Read “Code Complete 2” by Steve McConnell http://cc2e.com/ . This book has been the most influential force in my professional development when it comes to software craftsmanship. My college professors often pushed for good software craftsmanship, but it was never something I had a very good grasp on. This book is an essential read for any new (or seasoned for that matter) developer.
Advice 2: Accept that you’re not a coding hermit anymore. This has various meaning. A hermit is someone to lives in seclusion from society. Unless you are rich and can hire yourself to do the coding you want yourself to do you will probably not be a coding hermit. When you are picked up by a company or a university chances are you are going to be working with others for the goal of someone else.
Dropping the coding hermit attitude means integrating into the development norms of the organization you join. If your organization uses C, don’t complain and suggest C++, C#, or Java constantly, or refuse to work with C because it is inferior to the languages you deem “great” (on a side note learn about coding into a language from Steve McConnel’s book above). Do not reject the coding standards of your organization because you think they are archaic and wrong. The people who have worked on these systems have seen things come and go, and they know what works and what doesn’t. Some may even agree with you on all accounts, but they understand something you don’t, and that is that they are *not* building software for themselves, they are building something for someone else. I have to admit that I am a failure to my own advice when it comes to this, but that does not mean it is not good advice. I have come to learn and accept that the code I write is not for me. The trick is to identify places where you can break out of the paradigm your organization is stuck in. OOP is recognized as good a good SE practice, but if your organization is using functional decomposition you shouldn’t push them to OOP. I did this once, with good intentions, and most of the senior developers agreed with me, but they recognized that they are not coding hermits and are developing for the business. Building up OOP when you are working with legacy code written with function decomposition is a major undertaking, and unless your company has huge amounts of cash reserves to fund your R&D you will not get very far by suggesting OOP. As I said above, the trick is to identify places where you can break out of the paradigm. Recently I found a case where I had to de-serialize an object from XML into C. The code I was writing was for a layer outside the standard layer the other developers I work with generally write code for, and so I had the unique opportunity to play with “semi” object oriented C development (a.k.a. object based C development). Because the code was segregated I had the freedom to try something different, and I think what I attempted was a success, but this does not mean I will try to structure all my code this way. Until an architectural initiative steers me towards this, I will probably do functional decomposition for quite awhile.
I have a lot more to say about this, but this is supposed to be an overview of advice not a post about hermit coders. I may go into this more in the future, but for now I am moving on.
Advice 3: …
I can’t think of any other advice I have given at this time. I may revisit this post as I gain experience, but for now I think I am done. Again, I implore other SE’s to give me their advice or correct my own. My hope is that I pass on pearls of advice and not, for lack of a better word, “turds” of advice.