What is wrong with other programmers? (Of course not with you.)

I’ve been working as a CTO for a while already and I have this awesome opportunity not only to develop a code but also to lead a team, manage projects, design architecture, organize work, make code reviews, investigate different problems, research various solutions, get to know many technologies and contact customers. Uff, there’s a lot of that.

Across this wide range of tasks, I learned many different skills and made a bunch of observations which I’d like to share with you. Maybe your point of view is different, maybe you learned something else and you want to share your own thoughts here. I’m looking forward to hearing your opinion and insights.

This article is targeted to both CTOs and developers because each of us may not have seen some issues I’ve already observed, learned or solved.

Problem 1:
“I’m not familiar with technology/tool X”

This is a very common sentence I hear whenever I’d like to introduce some new technology or a language. This also happens when I ask someone to prepare a proof of concept with a tool they haven’t got to know yet.

It surprises me because I know I ask a smart person and, c’mon, a developer! Aren’t we able to easily learn something new? Some new concept, pattern or architecture? Don’t we continuously learn new things and follow the latest news?

Or maybe this is only an illusion? Maybe we feel comfortable with the things we’ve learned a long time ago and don’t want to switch? Maybe the truth is we don’t want to develop ourselves?! Maybe we don’t have time for new things? Maybe we can’t think differently?

After some time, I get the task done by someone I asked. They did it, they were able to deliver it. The initial hesitation was eventually overcome, the comfort zone was expanded. So what was the reason of lack of motivation on the very beginning?

I believe this is a fear of something new. A fear of a failure. We feel comfortable in what we do because we know it and we think we are good at it. The thing is that we can be good at everything else, we just need to want it, learn it and do it in the same way as things we’ve already done.

Problem 2:
“Overthinking on the very beginning”

This is one of the most common problems I see during the start new projects. Developers feel much more comfortable when joining already working application because fewer decisions have to be made. Starting a new project is different. We should decide and prioritize what is a requirement and what is a nice-to-have feature.

The biggest failure I can see is to implement, for example, an authentication on the very beginning. Isn’t it the most important feature of our application? Shouldn’t we care about security? No, not at all.

We should narrow the scope as much as we can. We should provide an MVP to show a proof of concept. We should deliver basic business rules, a core functionality of our application instead of taking care of the performance, pagination, super-secure authentication and extreme scalability. It has to be simple, at least on the very beginning.

How to achieve that? I think a talk with our customers is crucial here. It is their money that they invest and they are the one who pay us. We don’t want to waste their funds, neither he does. We should discuss together what is vital, what should be presented to their potential clients or investors. We can’t focus on things that don’t distinguish our application from the others like login/register features, change an email or remove an account.

Problem 3:
“Not choosing a right tool”

I talked many times with different companies about their development stack. Sometimes they do very fancy, concurrent and distributed things using… Ruby. When I ask why they choose this relatively inefficient language for such demanding processes, they answer that all of the developers know Ruby the best. Thus of course it is the fastest and obviously the cheapest approach. They actually don’t think about maintainability in a long run. They focus on a price and convenience. It leads them to a big technical debt and probably lots of hacking to achieve established goals.

The other thing is that many times I see developers choosing technology stack before they even get familiar with business rules. I see that among passionate developers all the time. They are so keen to start development and use all of the newest frameworks right away. They don’t think what a system will do and what problems it will solve, but they already have database and language chosen.

What to do in such case? My silver bullet is having developers who know many different technologies. After getting familiar with the problem and use cases, we can discuss pros and cons of tools we know or we don’t know yet. It’s good to have a wide insight on what is happening “on the market”, what frameworks and languages are out there and what problems they solve. Sticking to one tool everyone knows may turn out to be a pain in the ass during the development process rather than a solution for every use case.

Problem 4:
“Reinventing the wheel”

The problem is related to not getting familiar enough with a project that someone joins. It happens relatively often when I review someone’s code. I regularly ask: “Did you see that class/module/function? It does exactly the same what you’ve implemented”. This is common developers don’t browse the code that much. They don’t see that some of the functionalities can be reused without even extracting them anywhere.

This is especially true if we follow some common patterns, guidelines or architecture. It’s highly possible that some other developer solved this issue somewhere else or extracted and abstracted a functionality we need now.

To avoid it we should make more code reviews but in a wise way. We shouldn’t check if someone aligned parenthesis or added missing commas, it should be checked by some smart automated tools. We should review business logic and behaviors. After some time, we will think: “Hey, Kamil has just implemented it, I will use his module”.

Problem 5:
“Learning syntax, not programming”

I’ve met two groups of developers. Actually I can say about a third group which was a combination of the previous two, but it doesn’t matter for now.

The first group are excellent coders. They know every aspect of a programming language they use, they know a whole standard library and tons of 3rd-party tools. They know 8 ways to write a loop, how to use pattern matching and all syntactic sugar they can use. The problem is that they don’t know the architecture and paradigms. Their code is imperative, they can’t extract small functionalities, handle encapsulation and separate different layers or modules. They can just code.

The second group are awesome craftsmen. They are real architects, they model their application, extract components with a single responsibility, follow patterns and design effective flows. They just can’t code. Sometimes they focus too much time on a design that they use inefficient algorithms, deprecated functions, outdated libraries and only a small range of methods for just everything. Maybe an architecture is solid and a workflow is robust but a code itself looks ugly and is hard to read.

Where is the problem? The first case may happen when developers only read programming books related to a language they use. It’s like learning the syntax and nothing else. We think we know a syntax so we can program. Actually we can just write a code. The second case is when developers forget that maintainers or creators release a new version of their tools and languages. Programmers don’t read change logs, don’t follow the news and don’t read newsletters.

What is the solution? To have both types of people in one project. Everyone will be learning from one another and that’s how everyone will be satisfied and benefit the most.

Problem 6:
“Ignoring the patterns”

When someone jumps into a project that is already solidly grounded it’s likely that it follows some rules and guidelines. Usually, developers keep one convention per application to make it readable and understandable in every place.

Unfortunately, when someone new starts coding, it happens very often that they don’t see existing analogies inside an ongoing development. They use a different approach not necessary compliant with the current one.

We are so enthusiastic to deliver a new feature, that we don’t want to waste our time on observing current trends and patterns. We simply ignore established rules and introduce our own habits breaking consistency.

Is it bad? Not always. Sometimes, especially when more experienced developer joins a team, it can be very good. They teach others how to structure applications and shares with them their knowledge. It can sometimes bring a new view into an existing architecture and improve lots of concepts there. Actually, it happens rarely. Most of the time a new developer introduces a noise in big projects. This is well described in The Mythical Man-Month book which describes how adding a new team member may actually exceed a deadline rather than speed up a development.

What can be a solution? I believe having an introduction in a new project is necessary. We should not require delivering new features ASAP but let someone dive in into established rules. We should nominate a supervisor who will mentor someone on the very beginning and let him grasp all of the concepts.

Subscribe to get the latest content immediately
https://tinyletter.com/KamilLelonek

Summary

There are many issues in a programming world. All of us have different skills, different abilities and motivation sources. We are all very different even when we don’t think this way. We should talk to each other, solve problems together and make tradeoffs.

Learning is the key. Self-development should never stop. We are forced to do that unless we want to become poor programmers. This is our job to continuously learn and get to know new things.

Reading books is one thing, pair programming is the second, subscribing newsletters may be the third way and following blogs is another one.

Possibilities are limitless, we just need to choose what suits us the best.