5 Principles to be a professional developer

Actionable and relevant principles.

Being a professional coder is way more than just writing clean code. It’s about your behavior and your principles.

In The Clean Coder, Robert Martin describes 5 principles that will make you a more professional coder.

Although the book is old, its principles are timeless.

*I removed parts that are pretty common these days

#1: Commit to your professional development

Martin chose to put this quality before anything else. And that’s because the hours you put into your day job rarely contribute to your professional development and progress, because you are paid to do what you’re already good at.

To progress and get better opportunities, you have to learn new skills.

That’s why Martin suggests that you spend at least 20 hours per week of personal time to improve your programming skills and learn new ones.

#2: Practice discipline

In order to practice discipline, Martin mentions 9 rules you need to follow.

Here are the top 5:

Rule #1: Avoid doing damage. If you can’t, take responsibility

• Test all of your code regularly.

• Learn from bugs so you can avoid making the same mistake.

• Clean up bad code. When you come across something you know how to improve, refactor it.

Author note: The last piece is not 100% right. I once thought I can change the name of a variable using F12 (VSCode), just to find out someone relied on it in a string.

Personal suggestion: consult whoever wrote that piece of code before you change anything.

Rule #2: Don’t code while you’re tired or worried

If you’re not in a mental mode in which you can concentrate, you’re going to make mistakes and write bad code.

Rule #3: Don’t force a solution

When you’re feeling stuck, try the following techniques:

• Increase your content consumption. Consume creative content, like a sci-fi novel, to help you output creativity. If someone else’s work inspires you, you’ll want to create your own.

• Pair program. Working with someone else will almost always refresh you.

Author note: Going on a walk or dropping the task for the day is also a very good method that will make your creative juices flow.

Sleeping on it will have the same, or even better effect.

Rule #4: Finish properly

Completely finish all tasks before declaring them “done” and define “done” as “passed all tests”. Don’t accept partial completions for any reason, even if you’re short on time.

Author note: this is especially important, and might actually be the most important one. Delivering a half-assed task will not only waste more of your time, but it will also put you in a very unprofessional light and tag you as someone who can’t be trusted.

Always double check and make sure you are done.

Rule #5: Give and accept help

Sometimes you might encounter a problem that you find hard to solve, for any reason. Consulting a team member will give you a new set of eyes not tunnel visioned by what you already coded, to consider new ways to solve the task.

#3 Be Honest about deadlines

When you’re programming for someone, they always want to know when it will be done. And most times you will get it completely wrong.

So instead of giving a commitment, provide an estimate. Estimates aren’t promises, so missing them isn’t unprofessional.

Keep in mind that professionals do make their estimates as accurate as possible, so it’s not an excuse to miss deadlines.

Here’s what you need to factor in for your estimation:

1. Best case. If everything goes right, you’ll be finished in this amount of time. This number is very optimistic and there’s only a 1% chance you’ll make this number.

2. Nominal. This is the amount of time you think is most likely.

3. Worst-case. If everything goes wrong, you’ll be finished in this amount of time. This number is very pessimistic and there’s only a 1% chance you’ll make this number.

So the next time you give an estimation, mention all three numbers. It will make you much more professional in the eyes of others.

There’s one more thing you need to know.

People might not like your estimation and want it done faster. If this happens, you have three options.

1. Saying “no”. Although saying no has a bad rap in some cultures, it is the most professional thing to do in many cases. If it’s impossible to get something done properly by a certain deadline, it’s better to be honest and say no, then lie.

2. Saying “try”. Never agree to try to do something in a time period shorter than your estimation. People will often interpret “try” as a “yes”, which is a lie.

3. Saying “yes”. Only say yes when you know you can meet the deadline. Yes is a commitment. If it’s impossible to say yes to something in its current form, ask to change the parameters of the task so that you can say yes.

#4 Manage your time well

In order to be a professional, you have to manage your time well. There are three techniques professionals use for time management:

Technique #1: Attend meetings strategically

This is, arguably, the most time-wasting component in many developers’ day. Plus, they are expensive. They required renting a location and paying for the time of the attendees.

Therefore, avoiding time-wasting meetings. Only go to meetings if you’ll gain information that’s important to your current project, your presence will help someone or the meeting is about something interesting and you have time. The meeting also must have an agenda, schedule and goal.

Also, if an argument breaks out during a meeting, keep a handle on it by limiting it to 30 minutes tops. Further discussion isn’t productive and likely requires more data or more opinions.

Technique #2: Avoid priority inversion

This is when you avoid unpleasant work by doing a lower-priority task instead. (My favorite way of working 😜). Do your tasks in the real priority order.

Technique #3: Avoid and abandon dead ends and messes

Abandon a course of action as soon as you realize it’s going nowhere and try something else.

Not abiding by this technique almost killed an 8 months project in the first startup I worked for.

I wrote an app that was required to work offline and have building plans of specific buildings on the phone.

I started building a system that will download all the plans all at once, assuming an iPhone will be able to take the load.

I was wrong.

People had their iPhones heat up, downloads stopped in the middle and in rare cases their phones would shut down.

Instead of changing course, I tried to optimize it for 2 months.

At one point the PM stopped me and asked me to change course or they’ll have to shut down the project.

#5 Collaborate

Collaborating is built of two elements:

Element #1: Teamwork

The best way to collaborate is to put together a permanent team that works on multiple projects together because:

1. It takes time for a team to become effective.

2. Teams that work on multiple projects can better allocate strengths and weaknesses

3. The team can quickly adjust priorities.

Element #2: Mentoring

In addition to teamwork, collaborate by mentoring. It’s the professional and ethical duty of experienced developers to mentor newbies, and it’s newbies’ duty to ask for it.

Inexperienced coders can cost a company a lot of money and do a lot of damage.

What we enjoyed reading this week

1. The step-by-step playbook to hijack Spotify Wrapped 💿 by Tom Orbach

2. Emergence - Mental Model by Michał Poczwardowski

3. 🛑 Don’t Start Coding Yet: Here’s What Great Engineers Do First by Fran Soto