Dear Recent Graduate or Entry Level Developer,
As someone who has been in the field you have selected for your career for some time, I hope you will allow me to offer some (completely unsolicited) advice about our industry. I’ve been where you are: eager, motivated, and hopeful. I’m sure you’ll encounter plenty of people who will have their own version of what I’m about to give you, but take them all together and just maybe something will carry with you in your career.
Do this job because you love it
Software developers like us certainly don’t corner the market on passion for our jobs. But with passion can come great results. I heard early on in my career the suggestion to “find something you love so much that you’ll do it for free, then become so good at it that anyone will pay you to do it.” These days (compared to when I was in your position) being a programmer is a lot more trendy and mainstream. Those who have passion will sustain – those who are just on the bandwagon will likely flutter off to some other interest.
Learn to communicate
Software is a unique product in that it reaches out to all levels of business and society. In your job, you’re inevitably going to encounter customers, managers, and clients who may be executives and directors. I’ve found that most of the time, particularly when things are not working as they should, these people want answers, not deep technical explanations. Consequently, you need to learn to communicate effectively to lots of different audiences.
One key element of learning to communicate is knowing how to balance discussion on technology and business. Since in most cases, business rules the day (see below) you want to be able to engage with someone about their business, and also explain technology and its capabilities for them. Sometimes this is as simple as asking “Would you like me to explain how this works?” rather than assuming they want to know.
Additionally, effective communication comes by knowing and understanding the perspective of your audience. If you are speaking to a business owner or department head, chances are they have a very bottom line view of the world, so you’ll need to learn how to discover those core values and then engage the person in that context. In general, I find you’ll be much more respected, well received, and more likely to be invited back to the table when people feel like you can represent technology without making them feel overwhelmed or lost.
Business rules the day
With extremely few exceptions, you are going to work for an business. That business is measured by a very simple equation: revenues minus expenses equals profit. Some organizations pretend that they are about other things, like serving people or changing the world. But in truth they are measured by money.
You will be hired to either increase revenues, decrease expenses, or facilitate both. These two objectives will drive every decision, every meeting, and every opportunity that you will face.
However, many of us (myself included) enter the industry without really understanding how business works. We arrive, eager to write code and make something, never thinking that every hour we spend stuck on an issue is costing the company something.
Therefore, I encourage you to get a basic education in business principles. Understand the core principles of accounting. Know how your employer keeps score, that is, what are the revenue centers, what are the cost structures, and how does your effort directly affect the bottom line. To that point – know what the phrase “bottom line” really is talking about!
You will inherit someone else’s code, and someone else will inherit yours
In my parent’s generation, a worker would often stay with one company for their entire career. In my generation, and likely for yours, this is no longer the case. If you are on the same project or with the same company for more than 3 years, you may be the exception. As such, the code you write and the code you are assigned will have lots of contributors to it.
I say this because inevitably, the code you inherit will suck. It will drive you crazy. It won’t make sense, and you’ll long to be inside the head of the person who wrote it just to figure out what the hell they were thinking. And then someone will feel exactly the same later on in life with the code you write. If there ever existed an unspoken courtesy among programmers, it should be to try to make life easier for the next developer on the project. This is at its simplest a longwinded way of saying “put comments in your code.” But in the same way you’ll appreciate receiving those explanations, the ones who inherit the projects you have worked on will thank you.
Learn to do things right, not just make them work
One of the most cringeworthy statements I hear from developers on my teams when they get faced with a problem is something along the lines of “I just had to hack something together…” Hack jobs are ticking time bombs. A great deal of technical debt in the world is the result of hack jobs, done in a hurry, because someone didn’t want to take the time to do it right. Resist this temptation as diligently as you can.
If you feel caught between a problem and a deadline – go petition for more time. Most managers and customers are reasonable enough to understand that a quick fix is often a seed that grows in to an expensive problem down the road. Learn how to communicate that risk.
Present a solution, not just a problem
Finally, as a manager, you need to understand that I’m busy. My day is full of lots of things. So if you get stuck or have a crisis, just telling me about it adds one more thing to my plate. Here’s the better way to do it:
If you have a problem or are stuck on something that needs your manager’s attention, come prepared to explain the problem to them but also present your solution. Let me know that you’ve put some thought to this. You can ask for either my clearance to go do your plan, or a validation that your plan is reasonable and feasible. But most importantly, demonstrate to your team or management your ability to solve the problem, and it won’t go unnoticed.
Being a developer is a great job. It’s fun, rewarding, and will provide you a good living. I know it has for me. Go forth and code!
Photo credit: Jeric Santiago
14 thoughts on “Letters to junior developers”
Great article. I would say not just Junior developers but all developers!
Nice and interesting article.
I have shared this article for Sri Lanken developers.
Keep it up!
Loved your article!
Really nice article…
Thank you! I just began reading and I wondered whay you mean with:
If you are speaking to a business owner or department head, chances are they have a very bottom line view of the world
On this point… “You will inherit someone else’s code, and someone else will inherit yours”
This is what I tell my tutorial groups (many, many, many times). However, I also add that the “someone else” can also be your future-self of 6 months.
Great article, and very good advice.
As a Systems Administrator for more than a decade, I (most likely you) already managed/integrated various ERP migration and implementation processes, applications, technologies and so on.
Let me add that, in my humble opinion, what you state in your article isn’t just for “Junior Developers”, it IS for everyone in IT.
Most of our work is not easily measurable or visible, but have a great impact on our company (or clients) business performance, and this should be our main focus when heading to work every day.
I enjoy the article. But one thing that always bothers me is the part about picking up where someone else left off (inherit). Is it too easy for an employee to be replaced or fired after being too detailed in your comments that your work can be “taken” by someone else and that person is given all the credit? I’m talking about job security. I ask because my Java instructor back in college shared a similar story that happened to him at a previous employer.
Thanks for sharing those insights!
As a business student myself, just having finished a minor in Advanced Programming (Advanced algorithms, enetrprise systems and an Air Hockey robot project in C++). I can assure you that most of the students that I’ve worked with/been around would really benefit from this advice. Myself included, of course.
Will share 🙂
I’m a student, worked a few months as the only programmer on a job, my experience is brief but I’ve read everything about working as a programmer that I could get my hands on.
If time is money and you say we have it done now but we hacked it together versus give me a week and I’ll put it together right which do you think they’ll really choose?
I have read nothing but negative comments about the ability of management to understand such things. They aren’t about getting it done right, they’re about getting it done now.
Suppose you have a good manager, someone who will listen, if you go to them and say I need X amount of time how can they really trust you? After all, you failed to predict how much time it would take the first go around and now you’re saying I should trust you this time and that you’ll be right this time?
I’m just not sure that works unless you have someone rare.
Still I appreciate your thoughts in the article and if I really wanted to keep track I’d put a checkmark on the good manager side of the good/bad chart.
I’m a new dev myself and I am definitely going to start using some of these techniques! Thank you!
Not to start a flame war, BUT much of the software industry today, including the titans of clean code (Marty Fowler and his ilk) have started to push strongly against comments and more towards simple, modularized, clearly named, “self-commenting” code. It’s the same goal – help yourself and/or a future developer understand what the code is doing where, and how, and why – just a question of the best way to do it.
The most important thing is for people to understand both sides of the debate, think about it, and figure out what makes the most sense given their situation, including conventions of their development team. Unclear code is bad, but so is inconsistency because it confounds meaning as well.
Ariel – I don’t disagree that code should make sense in a way that another developer would easily be able to see what it is doing. My experience though, and what I had in mind in this article is more regarding the why code does what it does. To this end, a comment with an explanation of the conditions or situation or bug ID will help the next developer find some context for the operation of that code. All the same, good habits for naming and organizing go along way!
Thanks for commenting!