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
