I'm in the process of finding a new job, there is a new year coming. And I've heard somebody asking to another: "what does it take to become a professional software engineer?". So let's take that as an excuse to write a summary of the lessons I learned building web applications during the last few years.
I won't ask you to keep a good documention, even though you should. But at least, write everything you're doing. Even if it's a really simple and basic task. Instructions for how to install, to get started developing with your code, answers to questions you're answering a lot, post-mortems of major incidents in production server, etc.
From the managers team, to the developers team, from you to your teammates, priorities will be different. Learn how to find the right balance for everybody.
Estimating things that you don't know you don't know
After almost 6 years working as a professional developer, I'm still afraid when I'm asked for estimates. To produce quality software, you need time, being talented is not enough. Here is a list of situations where software estimates have good chances to be skewed:
- Tasks not granularly specified and too ambiguous.
- Unfamiliar technologies.
- One person estimating for another.
- Pressure by management to estimate because of political and financial agenda.
- Many more ...
When in doubt ask
As soon as possible, ask. A question, an advice, a feedback, an information, for help, just ask. To your colleagues, to the managers, on StackOverflow, just ask. Please, don't stay during days with a question that can be answered in two minutes.
No is a valid answer
There's a limit to how much you can do in a day. If you really don't know the answer. If you're really busy. If you don't have time. If it's impossible. If you really don't want to do it. Just say no. Everybody, including yourself, will save time.
Work from home
Personal and subjective opinion: open plan offices are a completely f*cked up idea, sorry. They are noisy distraction zones in wich you cannot get any productive work done. I just don't understand why everybody seems to be happy with that way of working.
All the jerks should be fired. And if they're not, you should leave, end of story. Just because you're able to write some sh*tty code, doesn't mean you should be condescending.
Have a rest
Working on saturdays, on sundays, on holidays, on vacation, when everybody is sleeping. It's worthless, it's useless. It just results in less effective work and in burn out. Do not get overwhelmed by your job, or by pressure of the deadline. Enjoy your free time, go out, have a drink, read a book, learn to move, meet new people, make new friends, keep in touch with family. And come back to work, on time, fresh, and well rested.
Dealing with the legacy code, pobably the most difficult part in your developer career.
That stuff, nobody knows how it works even the original authors. They've left the company many years ago, and they do no more remember what they were doing. This stuff really needs to be rewritten, but sadly, business people tends to think it's an asset, probably because of the huge amount of money they put in it. So, what should you do:
- Be patient.
- Do not try to understand the whole thing correctly in the begining.
- Everything in that codebase was done a certain way for a reason. Find it.
- Start by a url, and try to follow each function call until you hit the database.
- Do not try to abstract. Duplication is better than the wrong abstraction.
- Always make small additions using existing patterns/elements/practices.
If possible, do not share feature branches. As soon as you're done working on a feature branch, if the feature is finished and ready, merge it back to the master branch. And after the branch is merged, delete it. Do not allow a branch to get old in your repository.
Tests are useless, until the day you're developing a feature, on top of a code base you don't fully master. Or until the day you're doing some refactoring, and you don't know you're actually introducing regressions, somewhere in the code base. Whenever possible, write tests, for the feature you're currently developing. If possible, whenever you find a bug in production, write a test that detects that bug before you try to fix the bug.
Error monitoring in production
Please, you should have some sort of system that logs all errors in production to something more interactive than a log file sitting on a server somewhere. You won't like being called in the middle of the night to grep log files, looking for bugs.
Distributed systems are harder than one may think
You may have heard about the 8 Fallacies of distributed computing.
If possible, work on a team, and do code review or pair programming. You won't spend too much time alone running after a bug which is under your tired eyes. Also, there will be one other person that understands the code you've written. This is useful for bus factor.
Unless you're talking about a really small application, please, stop deploying using ftp.
DRMs are just complete black boxes, with no way of debugging. I was lucky to work long enough with some DRM systems, I mean, implementing them on the production server. Besides the fact that it was a complete nightmare, it wasn't even working correctly, on their side. DRMs sucks!
I still meet lots and lots of developers who do not want to share their code. Publish your work, contribute to free software, go public. Sharing code and reading other people code is an important step to reach for anybody who want to grow as a software engineer.
What can be done by friday driven development
Identify the next single smallest problem you want to fix. Write the simplest plausible solution, and test it. Your commit message states the problem, and then your solution.
I spent the last 2 years writing code, working on new features, and I spent the last 2 years without shipping any code to production. Something was definitely wrong.
Write a (programming) blog
Writing rewards you and benefits everybody reading you. When you write you learn something, you refine your thinking, you share your knowledge, you connect with your community. And you build credibility.
Learn a new programming language
Learn a different language and try the other mindset of doing things. That will makes you a fundamentally better developer.
More on the topic: