Professional Developer: What Does It Mean?

Miserable no-lifer

When I started to work as a software developer, I was happy. But only in the beginning… after a while, I was exhausted and irritated. Unfortunately, I got used to it.

I got used to going home late.
I got used to trying to do everything to meet somebody’s deadlines.
I got used to fixing a lot of bugs and debugging all the time.
I got used to angry clients.
I got used to programming in a hurry and leaving stuff for later.
I got used to my nasty code and my bad practices.
I got used to the hope that another project will be different.

I got used to all of these things. I thought that all of us, software engineers, got used to it and that this is a part of a developer’s life. I couldn’t be more wrong.

Become more professional

I wanted a change. I wanted to do stuff differently, to change the status quo. Then, I found Software Craftsman by Sandro Mancuso and it became my starting point.

I read a couple of lines and… I couldn’t believe it. This guy was writing about me! About my situation! I was so excited that I read the whole book in just a couple of days. Since then, everything has been totally different.

I’ve made a lot of changes in my approach to both the client and the project and I almost get rid of all the bad habits that I got used to. I created a kind of mindset or a list of rules for myself which I want to share with you. Maybe you have the same problems that I had and you will find these thoughts useful.

I’m not a great programmer. I’m just a good programmer with great habits
– Kent Beck

0. It’s not about You.

This is the most important thing and the easiest to forget. Why do we do what we do? Because someone needs a piece of software and wants to pay for it.

Very often, we think of ourselves as the most important person in the whole project team and we think about every other person as someone who is disturbing us – including the client.

Why? I guess that’s because we often care most about ourselves and our comfort. This is a shame. We have to understand that our work is not about us (and it has never been!) — it’s about our clients.

We have to do everything that we can, to help them make money on the apps that we create for them. We have to care about the project. We have to take responsibility and remember that we are for the clients, not the opposite.

Creating an app is a service like any other service. Let’s put ourselves in the client’s shoes.

What do we expect when we go to the cinema? Or when we go to the restaurant? Or… (just leave here any example when you are the client)? All that we want is to be serviced in a proper way, to get good advice and to receive help. We want to feel that somebody cares about our problems and needs, rather than just wasting our money. So, let’s just do the same for our clients.

 

The zero as a point number is not just because we are developers and we count from zero. It means that understanding this point is a base rule for any other rule.

1. Say NO! Be honest.

Let’s imagine a call with a client. It’s just another call that we do i.e. once a month. We tell him what we did, show him the demo and at the end he’s happy. Now we have to talk about the next, additional functionality that he want us to implement. “Easy peasy” — we think. “Hit us!”.

“Guys, I want to have feature X and Y in my app. But I need them in a month.” — he says.

“Never gonna happen. We need at least two months because we implemented similar functionalities in a couple of other projects.” — we think, but we instead we say — “Hmmm. Eeeem… Actually…”.

“C’mon guys! I know that you can make it! I’ll have a very important meeting that day and a lot of money depends on this. I am counting on you.” — he says.

That’s when we say the worst thing that developers say… WE CAN TRY.

We always say that! This is the beginning of a catastrophe… Saying that we can try, we’re essentially signing the following declaration, which says:

During this month, you will be more and more exhausted. You will stay at work late and drink a lot of coffee. After a month, exactly in this room, you will be embarrassed because you will ship to your client a piece of shit and you will have to act like this is good software that represents the best that you could do.

Your client will take this ‘software’ to the sponsor and the demo presentation won’t go well. This client will come back. Oh he will! And he will be furious. Everybody, including your boss, will be looking at you and think — “Why did he give the client such crap? Is he a good developer?”. You will be depressed.

Unfortunately, the content of this pledge is written with the use of invisible ink. So, all we see is the blank paper. We look at it and we signed it — “Yes, we can try.”.

What exactly does “trying” mean? If you don’t waste your time at work and your responsibilities are connected mostly with this particular project, it means just two things:

1. You will be doing a lot of overtime.
2. You will be coding in a hurry.

Because of the first one, we will stop being productive after a while. It means that we can’t do the overtime all the time and then we come to the second point — coding in a hurry. “Coding” is a big word because, mostly, we will be trying to fix bug after bug. “Coding” is a big word because we will often be trying to restrain dragons.

Surely, we will be running out of time, so the dragon’s family will find cosy places in our code. Then, we will find out that the sexual life of dragons is very similar to the rabbits’ sexual life so, after a short time, dragons will be flying everywhere. So, overtime and coding in a hurry will be interweaving until we hit the deadline.

We know all of these things, so why do we still do this over and over again? I guess it’s because, each time, we actually start to believe in this unreal estimation.

“Ok. It will be hard. We’ve never implemented these functionalities in a month BUT THIS TIME… This time will be different.”

We walk out of the room with the big “S” in our chests and we start working. After about two weeks, we start realising that something is going wrong because we are in the middle of the first functionality. Then J.K. Simmons from Whiplash appears in our heads and yells at us — “It’s not my f****** tempo!”. So we speed up the tempo! — staying late at work and coding in a hurry. The content of the pledge is more and more readable.

What can we do to never let it happen again? Just say NO!

No! Try not! Do or do not. There is no try.
– Yoda

Listen to Yoda! But what does it mean in practice? Let’s go back to the conversation with the client. This time we’ll say NO and you have to be brave!

 

“C’mon guys! I know that you can make it! I’ll have a very important meeting that day and a lot of money depends on that. I am counting on you.” — he says.

“It is very important for us as well. But if we tell you that we will make it by next month, we are lying to you. These two functionalities can’t be done entirely BUT we can do the whole first one or the whole second one. We can even do both but without any logic — just the views and animations, while the rest will be hardcoded. What do you need the most for this demo?” — we respond with confidence in our voices.

Boom! That’s what it should sound like! Even if we don’t know how much time these two functionalities will take, we can simply just ask for a couple of hours to estimate them and call back to the client with suggestions.

Believe me, our clients will trust us more if we say NO because it means that you care about the project. Each client wants to know the truth and wants to know about each impediment because that helps them plan the next steps and react accordingly.

So, be honest with your clients.

2. Keep the code clean. Don’t be the king of the dwarfs!

The code is a reflection of your soul. Think about whether your soul is a piece of shit.
– me

Let’s make it clear from the beginning — the clean code is not the code that I understand. Clean code is the code that I understand at a glance! There is a subtle difference between understanding and readability. But I don’t want to write about rules of clean code because it’s not my point.

The question is — why should we keep the code clean? Again — because it’s not about us. It’s quite rare that we are working on a project alone. Because of this, we should do whatever we can to write the code in a way that it will be easy to read for others developers in our team. Easy to READ.

Even if we work on our own, we have to think about the developers who will be maintaining this code. Don’t let any dragon out of your code. Not even one little dragon. Not even the sweetest and cutest one. As I said before — one little dragon will grow for sure and then it will copulate… That’s the sad truth. I guess that it may be connected with the broken window theory.

By the way, when I thought about this dragon metaphor that is so popular, I realised that the Hobbit movie is about developers! The dwarf king simply just neglected the castle and, because of him and his mistakes that he didn’t care about, the dragon came. The dragon drove everyone out and everyone was afraid of him. They need an expedition and the bravest man to expel the dragon! How isn’t that similar to our work!?

 

Ok, let’s go back to the point. For some reason, we think about each app as our own. But these are not our apps. Each line of code that we write is not ours — it’s our client’s. We should not stick to the code and our solutions. Even more than this, we should not trust our own code! That’s why we need Code Reviews and Pair Programming. We often dive deep down into the problem, so we can’t see the simple solution and then we complicate the code as a result.

The same applies to the cleanliness of the code — we think that it’s clean but, in fact, we understand it because we have been writing it for a while — it’s not the same. We have to be open-minded to see this or to be willing to see if somebody else can say that the readability can be improved in one of our commits.

3. Don’t be a boiling frog. Keep the temperature down.

In Pragmatic Programmer it is said:

We’ve never tried this honest. But they say that if you take a frog and drop it into boiling water, it will jump straight back out again. However, if you place the frog in a pan of cold water, then gradually heat it, the frog won’t notice the slow increase in temperature and will stay put until cooked .

 

In this metaphor we are the frog, the water is our project and heating the temperature is caring just about ourselves and nothing more. Let me give some examples:

• When we are totally inactive during our daily synchronisations and we are not interested in what our colleagues are saying, as well as what problems they have, because we think that those aren’t our tasks and our problems, then we heat the water.
• When we didn’t understand something during the call with our client and we didn’t ask for repetition, counting on other team members to understand it, then we heat the water.
• When we do everything in our own way, despite any priorities, documentation or arrangements, then we heat the water.

And so on and so forth.

We can imagine the results of that kind of attitude — an angry client, a bad atmosphere in the team, unreachable deadlines, a lack of knowledge about the project and a lot more. We can’t be like that.

Ok, but how can we be sure that we aren’t heating the water?

Just listen

Listen to what others are saying. It’s as simple as that. Be active during meetings, ask questions, let the team know that you care about what they are doing, as well as their problems and that you are willing to help. The same applies to the clients. We have to know what is going on in other parts of our project, just in case. Let’s say that one of our colleagues are going on holiday or just leave the job. The deadline will stay the same and the work needs to be done. So, listening and being active is a good approach if we want to stay connected with the project and potential problems.

Use simple words

Don’t talk technically for the whole time. Remember about the team members which aren’t technical. For example, design guys, testers, Scrum Masters or clients. Every time we forget about this, we heat the water for somebody else in our team. Of course, we should expect that when someone doesn’t understand us, he will ask a question, but… how many questions is that person able to ask? If we keep talking like we are into the code, he will stop asking. He will be ashamed because of us.

We have to find a common thread and use a language that fits everyone in the room. If we don’t, we will heat the water for someone else.

I guess that we often use the technical language on purpose — because we are tired and ashamed. Usually, tasks are underestimated by us — each one looks pretty simple. How many times has a task been estimated for several hours and yet we found ourselves doing it for a couple of days? Often such tasks prove to be more difficult than expected. Sometimes, just debugging was time-consuming but the solution itself was very simple. In these situations, our motivation goes down.

In front of the client, project manager, or even the dev team, we use complicated words to avoid letting them know that this task proved to be very simple at the end, but took us a lot of time. Unfortunately, we heat the water by doing this. Just be honest with the team — it may be the trigger that lets everyone think about changing the architecture or just do a more sophisticated refactor.

4. YAGNI. Do what has to be done.

You Aren’t Gonna Need It.

How many times we do stuff that we think we will need later? How many times do we complicate the code because some solution takes 3 lines of code instead of 8 lines?

When we have to do a task which says: “User sees exactly 3 pictures with descriptions below them”, we actually read it in that way: “User sees exactly 3 pictures. ‘Exactly’, hmmm, it probably will change in the future. The task requires pictures, but I’m sure that videos are on the way, so we have to be prepared for that. For now, the user just ‘sees’, but what about clicks and other events? This task is more difficult than I thought”. Of course it is, because we complicated it!

Do what has to be done. Nothing more and nothing less. If the code will be clean, you or your colleagues won’t have any problems adding other cases IF the feature develops.

Maybe this is not the YAGNI itself, but I feel this is worth mentioning. I’ve noticed that we are proud of ourselves if we turn five lines of code into just one. Even at the cost of complicating the code. If this one line of code is completely unreadable, we should rewrite it back again to five lines. We don’t want unreadable lines of code in our project, do we? I don’t wish for any of you to work on the project in which developers turn every 5 readable lines of code to one smart, but unreadable one.

5. Refactor. A lot. But not every code.

Refactor should be one of the things that we do all the time. I mean it. Before each new implementation, we should first do some preparation and cleaning. It should be like in real life. When we see some garbage on the floor, we pick it up and throw it into the trash bin. The same goes for dinner — we do some preparation before cooking, including cleaning.

The same behaviour should accompany us during our daily work with the code. Keeping everything clean and removing each small piece of dirt. Immediately! Each “later” is another small dragon or a broken window. It’s very important to not just stop after we understand the code but to refactor it if we didn’t understand it at a glance. We should make it more readable for others. Thanks to us, they won’t waste the same amount of time to trying to understand it.

But we have to be pragmatic. We shouldn’t refactor everything, every time. Refactor the code in places that change a lot, or in places in which we have to add something new, is a good approach. But taking time to refactor a piece of code that was last changed some months ago, with no bugs reported or connected with it, is not a good idea.

Let’s say that we wrote a login functionality six months ago. After this time, we have developed, we have more skills and so on. By accident, we looked at this code and it was terrible… We can’t believe that we wrote that… But there are no bugs reported on the screen.

“Hmm… But eventually, we will we have to do this refactor, right? We can’t just leave this terrible code in the project, so let’s get started.”

NO! Leave it! Even if we have nothing to do. We shouldn’t touch the code that changes very rarely, or even never, and it’s working. Why? Simply put, because we don’t need to. It’s a waste of time and when we don’t have unit tests, something can go wrong and the login may be damaged.

We should change it only when we will have to add something — i.e. another way of logging in, like a Facebook login button. Then, you should prepare the code for this change or check if it can be done without refactoring. In this example, the changes in login functionality happen once in 6 months, so we have to be pragmatic in the first place.

Conclusion

Becoming more professional is not a simple thing. I’m not professional for sure, but not YET! I try every day to do the best I can. For sure, none of us will be a professional developer in one day. It’s a long way to go. Every day, we can do something to be a bit more professional. Take responsibility for the client’s project, be active during the meetings, do simple refactoring of our code — something every day. Even a small thing is another step on our way to professionalism.

Let’s start from today!

---

The post was written by Mateusz Budzar, Droids On Roids Android Developer. This and other articles of Mateusz you can find also on Medium 

Related posts