Being a good developer isn't just about code...

Hello there,
This week we're going to talk about what makes a good developer, but not in the way you might think.

The idea for this article comes from the discussions I have with my customers and why they enjoy working with me.

This article also comes from the fact that, last weekend, I was taking a look at the state of the infrastructure on which this site (and the customers) are hosted, and in two years a lot has happened....

Are you ready? Then let's get started.

What this article is not

In order to avoid wasting the time of those who aren't interested, on this article there will be no debate of "What's the best tech?" or "What's the best language?"
The idea here is to delve deeper into the profession of developer, and, even more so, freelance developer.

What does a developer actually do?

Many people see a dev as someone who spends his time writing code, but that's not quite true.

The question is, why do we write this code?
To solve problems and meet needs.

Code on its own is absolutely useless; code is a tool for achieving objectives.

Of course, in my life as a freelance developer, I spend a lot of time writing code, but the time when I find myself most productive is when I'm lost in thought, pondering a situation I'm confronted with.

This has happened to me several times, for example last week, in a project I'm currently working on, the user experience wasn't satisfactory enough for my taste, so I put the problem aside and carried on working on the project.... and then I went for a walk.

Later, as I'm wont to do, I was lost in thought in a well-known Nancy park, and after about ten minutes of walking, the solution to my interface problem came to me... just by thinking.

On the way home, I tested my idea and wrote the few lines of code needed to implement it. It boiled down to about 20 lines of code (in a stimulus controller, for those in the know).

So there you have it, 30 lines... but it's not these lines that are valuable, it's the idea behind them that enabled me to find the solution to the problem that is valuable.

(I'll tell you more about the project in a future article, it's coming along nicely).

Understanding your customer and his needs

It's a mistake to think that your job is simply to "come in, code something and leave".
In fact, there's a whole lot of work involved in understanding your customer, their world and their needs, and it's even possible to discover needs they didn't know they had.

Let me explain: my clients range from small and medium-sized businesses to large groups and entrepreneurs embarking on a new adventure.

This paragraph is a nod to the latter.

Some time ago, I had a project where we were talking about launching a "new media" (same thing, more on that later). I understand what we're talking about, but I'm already looking further ahead.

Basically, the media was available in French and English, except that in writing the CMS (based on Ludo Dev CMS) for this project, it seemed a good idea to anticipate certain things, such as the fact that, like any business, this media will evolve over time (a business : either it grows or it dies, there's no in-between).

As a result, the language module has been designed with the future in mind. While it supports French and English, it is already compatible with all languages - in fact, there are no technical limits, just translation files to be added.

Finally, on this same project, although the customer initially wanted 4 well-defined categories. We had to go the other way and allow as many categories as necessary, so that he could add as many things as he wanted over time.

At first, it was complicated, because the customer wasn't into tech, and he saw that the categories on the test site were "test 1", "test 2" ... etc..

Then, when he understood what had been done, he just said "Thank you".

The idea here is to understand your customer's needs, but also to propose things to them, and to do this, you need to enter their world and not just "execute".

The end-user is not necessarily who you think he is

In fact, the customer is one thing: he believes he has needs and thinks he knows how to meet them, but this isn't always true.

In e-commerce, for example, many people think that all they have to do to sell is set up an online store, and that their biggest problem is the technical side of things.

Well, if your developer isn't bad, who cares about the technical side?

On the other hand, selling online isn't that simple. There's a lot of competition out there, so you need to know how to stand out...

Once again, this is where the developer can play an important role: you need to imagine the users of the e-commerce platform you're creating. How do they perceive the web?

The idea for a dev isn't to say "wow, I'm going to use React for this", but rather to say "how can I make their lives as easy as possible?".

Making applications is fine... applications used by lots of people is better. And if, on top of that, users enjoy using the application you've been working on, then that's great...?

The world of developers and real life

This paragraph comes from a tweet I saw:

"Devs who don't test are morons".
This sentence was apparently uttered in a coworking space.

In fact, in the small world of dev, there's a disconnect with reality.
The idea is simple: a company, its life and evolves, sometimes with big constraints and sometimes with emergencies.

When you arrive on a project, you find it "as is", but you don't know why certain decisions were taken and why.

Take, for example, the case of a company that grew very quickly. At the beginning, it had few resources, so it made do with what it had.

And proofreading all the code takes time, time that the company certainly didn't have.

For testing, it's the same thing: development "best practices" say that you have to test.
Of course, except that this is often disconnected from the real market, which is constantly changing and evolving.

If we look at what happened in 2020, everything was turned upside down in less than a month... we had to adapt. So it's not surprising that unit and functional testing were not a priority.

The idea here is that: dev is one thing, wanting to do things right is fine, but sometimes you have to take shortcuts because the situation demands it.

I've lost count of the number of times I've made a modification "in the view", on a product page, rather than coding an editing system properly... well, yes, but the need had to be met at the time. This was very important to the customer.

Creating solutions that adapt to needs, not the other way around

This paragraph is simply a continuation of the last words of the previous paragraph.
Sometimes we may think that, as developers, the world has to adapt to us, but that's not the reality.

Computer science and the creation of tools are there to meet the needs of the world around us.

That's why the tools we create have to be designed with the problem in mind.

On the project I'm currently working on, even before writing the first line of code, I had a clear picture of what needed to be achieved.These opportunities have been seized with a view to making the final product even simpler to use, and therefore even more appreciated by its users.

In the same vein, there's the case of Twitter Bootstrap, which is sometimes criticized by front-end developers, yes, but it meets a need. If it served no purpose, it wouldn't be so popular....

Conclusion

This article clearly goes against the grain of all articles on "the best stack" and "the best language". The idea here is to understand whether you're working freelance with clients or as an employee. A customer or employer will work with a developer, because the latter provides real answers to their needs.
Simply coming in and writing code only works in very large companies.

But even in these big companies, if a developer wants to have an internal career plan, he'll have to know how to adapt.

Have a great week?