20 things to make your life easier as a developer

Life of a developer ain’t easy. We live double lives, torn between idealistic ideas (yackety-yack?) of a top-notch software quality and, well, life; deadlines, cutting corners and writing software without a single test. I know, I know, but uncover your bleeding ears, that’s the truth — your code will never be perfect because the circumstances will never be ideal. But here’s what you can and definitely should do to make your life as a developer better and easier for those (the future you counts as well) who will work on your code after you. Have you ever worked on a piece of code that you couldn’t understand and after an hour of trying to understand what the heck is going on, you’d go in your VSC and hit Git Blame and you’re like I swear, whoever wrote that code…

StateOfTheArtComponent my ass...

Who the hell wrote it...

Oh...

Yeah. Sounds familiar?

1. Document your code

Other people do not have the same context as you have. It might be as simple as naming the variables correctly as a way for your code to be self-explanatory. Do not use mysterious abbreviations; rename that getA to getActiveLayer — you might be surprised how misleading it can be.

Review your README file. When a new person comes aboard you want to make it smooth for her. You don’t want her to lose precious time on her first day on fighting with something as straightforward as setting up the project. You’re that newcomer and some things are not up to date in the README? Drink some herbs, swallow your frustration and FIX IT. Remember that the best way to teach others good practices is by setting an example yourself.

2. Do not trust the server

…or anything that comes from outside into your shiny component. Check for nulls, implement fallbacks for potential errors or nonexistent data. I don’t care that the API promised to give these results; if it won’t, that’s your page that’s going to crash.

3. Communicate decisions

Or better. Include your team to make them together. You’re just starting a new project and thinking of what routing solution to use. Or thinking of a perfect git flow for your use case. Communicate your thoughts and assumptions clearly but be open to other people’s suggestions. Do not leave it out of the discussion and go silently; you will leave your junior developers confused while it’s a perfect opportunity for them to learn about how you go about making decisions. And you never know, others may surprise you with a better solution to the problem. Once you all agree, go to step 1 and document that for future developers.

4. Estimate honestly

Hey. I’ve been there. Deadline’s approaching and you want to get it over with. But that’s you right there lying to yourself. Estimations are hard so don’t make them even harder by assuming the best scenario. You might be thinking that this dropdown looks fairly easy; you used it a thousand times before and you implemented it, well, a bit fewer times. But have you considered the data parsing that’s included in this task? BTW, you know that the backend isn’t ready yet, right? And you remember that the backend engineers are evil and are not going to serve you the format that you’d love to have, yeah? If you decided that you will use a library to write that dropdown component, have you checked how to change the default CSS styles? How can you add functionality that’s missing? Is it even worth using that external library or better write your own? Think of all of these cases when estimating tasks. Have I convinced you to scratch out those 4 hours you initially thought of?

5. Give a thorough description of your PRs

Maybe if you’re a mind reader you might know what are you going to be reviewing. I doubt it though, I think that person would have to sit with you in the same room and you’d have to be a 17th-century witch. The more information and context you give about your PR, the better; write about the business logic you introduced and that CSS !important you had to use because you’re using a 3rd party library — you will save yours and your reviewer’s time on reprimanding you about that !important and you explain why you had to use it. Before you open a pull request; give an additional scroll through the changes you made. Maybe you forgot about removing that console.log or you left a magic number.

6. Lift as you climb

If you already have a couple of years of experience, you might not remember how difficult it was when you were a junior developer (zapomniał wół jak cielęciem był). Mind you that you also can be a junior in things that you haven’t encountered yet. We all have these moments at least a couple of times a day. Mentor others; explain why you did things the way you did. Come up with new metaphors for that reduce function. Do a pair programming session. Give a hand once in a while. Suggest someone else lead that meeting. Be kind in the process and be humble, no one likes condescending people.

I promised 20 things but here you have 6. You probably already hardcoded 20 items and now you have 14 undefined’s. Oh well, don’t trust the server and stay tuned for more 📻 🙌