« You know nothing Andreas… » - Chronicle of a 27 years old developer
By: Andréas Hanss
Tags: JavaScript, Software Development, Coding, Software Engineering, Programming

Experience feedback

The Chronicles of a 27 Year Old Developer in the Software Engineering World

What I’ve learned (so far) from working at big companies, and some principles that inspired me

“You know nothing Andreas”

I used to be someone that takes shortcuts and learns on the go, then whenever I need it, I read the documentation. Most of the things in my life are that way: act, then step back and consolidate.

Did I take the wrong way?

You know what: by doing so, it worked pretty damn well so far 😆 Until I understood one thing by dint of making applications :

The software complexity naturally increases and we cannot avoid that: We call that the software entropy.

The thing is that this curve is not linear as we might think: it’s exponential.

What does it mean is that you need to take into consideration the future (even if abstract) of your program? Is it a one-shot program? Does it expect to grow highly? If you don’t think about that, you’ll probably go straight to the following case quote.

« Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. » — Alan Kay

Many developers think they master programming because they know how to use some frameworks. Many managers assume they can just add human resources to some projects and the productivity will increase.

But I guess, all of this is a bit more complicated.

My way on the developer career in a nutshell

Since my childhood, I’m passionate about computer science. I fell in love with automation and algorithmic. It even helps me represent and understand many concepts of life that are not directly related to IT.

I did short studies because I didn’t really trust school or even private ones with the hidden business around them. I learned almost everything on the field or with experimented pairs.

The school illusion

At school, I learned what I might consider today « a good way of building software ». Things like Xtreme Programming, design patterns…

But there was an issue: I was not ready to assimilate and fully understand that knowledge at this specific moment.

I was also young and dumb. I had not the same cognitive capabilities and abilities to focus, assimilate, and put to work what I was learning.

I thought wrongly that discussing with my classmates was more fun and relevant at this time than really try to understand what I was learning and why it would be awesome to apply it in my whole life.

During school, you lack real feedback on your work, everything is pretty abstract. School is good, but it’s not enough.

The sad truth about Digital/Software Service Companies

After school, I joined a company and the labor market.

I quickly started specializing in a specific framework because everybody was doing such… Without really asking myself about that.

I learned a lot from experienced developers, that was great.

But the truth was that I was just producing code like a worker in a factory chain. Some things felt so irrelevant at some point that I started thinking about how to bring change. However, the inertia in such a system is just overwhelming and I couldn’t make things change even if I wanted to. I was not even sure if what needed to change (according to me) was really the issue or if I was wrong.

One thing that I’m sure of is that with the big agencies, while it’s never clearly stated and assumed: code quality is amputated for the deadline, the market concurrency, and the budget.

Most of the time, miscommunication and misalignment within teams or with the business cause the majority of project failures or difficult situations.

That’s the truth about a great number of big companies, they are soul harvester and press people like lemons until all the juice went off, many developers share those feedback in terms of burnout.

Suffering from the Dunning-Kruger effect

Even though after practicing a lot at work and in my free time, I was improving my skills and I thought I was a good developer, even a really good one.

I was using the last available technologies like GraphQL, Javascript Superset’ Typescript, modular architecture.

The truth is that I was still doing shit code with big transaction scripts where instructions are just chained one after one and with no real dependencies management. My code was greatly coupled to one or two technologies or frameworks and I had no possibility to change that layer.

What happened to me is perfectly described by a cognitive bias named « Dunning-Kruger Effect »

In the field of psychology, the Dunning–Kruger effect is a cognitive bias in which people with low ability at a task overestimate their ability. It is related to the cognitive bias of illusory superiority and comes from the inability of people to recognize their lack of ability. Without the self-awareness of metacognition, people cannot objectively evaluate their competence or incompetence. — Wikipedia

TLDR; A beginner usually does not know enough about a field that he becomes totally biased on his or her ability to accurately assess his or her positioning concerning these skills.

The truth was that I was still not able to deliver proper software, even with cutting-edge tools.

Most of the time I delivered, but you know: Every delivery I wasn’t really confident.

Back to basics

The more you learn things, the more you understand that things have to be simple.

By not having cutting-edge tools bringing solutions to my problems, I started thinking about the « first principle » which is a way to reason about the most basic building blocks of somethings.

Then using that method, I built an inverted dependencies tree around that problem.

Elon Musk in the following video explains how he used first principles to build cheaper batteries.

Then I started reasoning: in the IT-sphere the most basics things in my opinion are :

Making a product that fills a business need

Beings able to maintain, adapt this software to this business need

Until that moment, I was thinking about how can the product needs to fill my technologies requirements (and hype), but in fact, it should’ve been the opposite: What are the tools and the code required to fill my business need?

After searching around that, I found back my old lessons at school and also much content about something called Domain-Driven Design or Clean Architecture.

Digging deeper, I’ve rediscovered software architecture and the ways to build my applications. Those ways of thinking teach how separating the core value of my software from the implementation details (like the framework) could be beneficial. When we can define clear boundaries in-between domains and build everything from the business need, our application becomes highly modular and aligned with the future requests of change.

Today I’m here, and after more than 10 years of development, I’m still learning a lot of things and I will probably in the future.