Even after 14 years as a Web Developer, I don't think of myself as a great developer, but I've always been curious about what it takes to become one.

So here's a short recap of what I've learned so far.

1. Communication

Success often come from doing the things that give you a non-linear outcome compared to the effort you put in.

Think Pareto principle.

If I had to say what's the thing that takes 20% the efforts to get the 80% of the value in programming, I'd say "Communication". Because programmers need to know exactly what's required by the stakeholders.

And the 20%-80% thing for successful communication with a human, is humility. Humility to remove yourself from the equation, and ask questions without the fear of being seen as stupid.

For this, there are many things you can do:

• Treat your anxiety, if needed (This helped me a lot)
• Practice being rejected. It's easier said than done, but there's a good book that you should read about this: Rejection Proof, by Jia Jiang
  Tips:
  • Practice deep breath before speaking to someone before being rejected.
  • Consider the fact that one day, you will die, and the other's rejection will be meaningless.
  • Consider the fact that everyone has issues and everyone is self-conscious and don't want to be rejected themselves, so most people won't make a scene while rejecting you.
    Just because they wouldn't like to be humiliated themselves.

2. Using the flow

Getting into the flow

The state of flow is what you want when programming.

That's where you're the most productive and focused.

A sure-fire technique I use personally, is to close my phone, close my office door, and put on my sound-canceling headphones.

Then get into the context of your work.

Your work's context is maybe your IDE + a browser opened in another screen. Maybe with a certain playlist in the background.

You get the point.

(Read The Art of Impossible, by Steven Kotler. It is fun to read and explains in details the concept of Flow.)

Note regarding procrastination

Some people say it's bad, some people say it's good.

I say neither and both.

That said, I really think that in order to be motivated, you need to understand yourself and the motivation triad (More on that in The Art of Impossible):

1. Curiosity
2. Passion
3. Purpose

You need to find work that fits into at least one of these. Or find one of these in what you need to do.

Staying in the flow

For staying in the flow, you'll want to remove notifications.

Read Deep Work, by Cal Newport for more info on that.

This is required reading for anyone using his brain to pay his rent.

Also, learn Vim. Just to avoid losing focus by going from your keyboard to your mouse to do simple stuff in your code.

With Vim, you can go from any file to any other file, and from one place to any other place, without your fingers quitting the safe zone of your A-Z keys. It seems like a small thing, but moving like that in your code helps you tunnel-vision in what you're doing.

You get into a place where the only thing that exists is the code.

You don't even think about your keyboard, because you know how to type without looking at it.

You're only conscious about the abstract concepts and their inter-relationships within their ethereal system.

Even time is no longer part of your consciousness.

Getting out of the flow

You want to stay inside the flow for 1h to 2h. You don't want to overdo it.

Your brain needs rest, to process the information (pattern matching, forming long-term memory, etc).

Note about the Pomodoro technique: it's great for some forms of work, but for deep, creative work, I recommend longer stretches of mental efforts. Having a pomodoro timer can be a distraction more than anything. Getting out of a flow phase is something that should come naturally. Like when you feel stuck.

The BEST time for you to get out of a flow state session is when you're in the middle of something fun and satisfying, but not quite done yet. Or put more eloquently:

I had learned already never to empty the well of my writing, but always to stop when there was still something there in the deep part of the well, and let it refill at night from the springs that fed it.

— Ernest Hemingway

That's because, then it's easier to...

Get back into flow

To make it easier and effective for you to go back at where you were in your code, you need to make that process...

1. obvious
2. attractive
3. easy
4. satisfying

For more info about those 4 laws, (that are the 4 laws of habit forming), Read this other mandatory book).

Small trick: Run it

Whether it's an SQL command, a Shell script or a Web form, that you're working on, the easier, most obvious and direct way of getting your brain back on track is to get the last feedback you got.

Starting from a compiler error that's easy to fix is the best for that.

3. Resting

Get enough sleep, do some exercise, etc.

Yes.

But the thing I force myself doing since many years now is simply: keeping my Sundays holy.

That is, I engage in no effortful activity.

I don't work. And if I can, I avoid any kind of important purchase. Except for the purpose of eating on that same day.

Tips on getting back to normal life away from your monitor:

• See your friends and develop relationships.
• Talk to you mom.
• Read a book.
• Get lost at the library.
• Etc.
• GO TO CHURCH.

4. Managing your notes

• Have a notes crate. It's not a Zettelkasten per se. Just a single place where you put your written notes, diagrams and mindmaps (paper format). Mine is pretty simple:
  • a plastic box
  • with one folder per year
  • with a year-by-year (1 page per year) index where I write the name/title of every document, next to a number (Identifier)
  • I identify each document I put in it with a small post-it flag like these on each of them, to find them easily by their number
• Have a BATF
• Have a central repository to store and find your snippets of code, instead on relying on Google to get you to that same StackOverflow thread again and again.

5. Tightening the feedback loops

Take some time to set up a test suite for the things you're coding.

Think of all the shortcuts you could take so you know that your code is working properly.

Think about the tools you'd need for you to be more agile during your development.

A great example is the livereload-kind of tool, when doing front-end development.

6. Debugging / Understanding

⚠ OBVIOUS STATEMENT AHEAD ⚠

To debug, you need to understand what's going on in the code.

— Julien Desrosiers

For this, take the time to draw an ERD diagram of the concepts being used in your code.
Or a sequence diagram if that makes sense.

Write down the list of classes and methods in the codebase, that are obscure to you.

Reduction

Reduce your bug, or whatever you're trying to achieve, to its simplest expression.

It's the dark corner of your codebase that's going to bite you.

Regressions

For debugging regressions, learn how to use git-bisect.

Learn to use your language's/environment's debugger — or var_dump() your way out of that buggy state, when using PHP ;-) .

7. Keeping things simple

You know what I mean.

8. Creating good lego bricks

Being a programmer is not only building things with lego bricks...

It's building your own custom lego bricks.

Good lego bricks...

• are reusable, because:
  • they are pure
  • they are small
  • they are simple, which makes them:
  • are obvious / predictable
• and therefore beautiful

Even complex systems are made of simple lego bricks

[...] individual atoms can be combined to form molecules such as polypeptide chains, which in turn fold and refold to form proteins, which in turn create even more complex structures. These proteins, assuming their functional status from their spatial conformation, interact together and with other molecules to achieve higher biological functions and eventually create an organism.

[...] At the highest level, all the biological communities in the world form the biosphere, where its human participants form societies, and the complex interactions of meta-social systems such as the stock market.

Source: Emergence: Living, biological systems, Wikipedia

Likewise, a human brain is made up of neurons connected to each other, with chemicals and electricity.
But from those emerge human consciousness.

Think about it, next time you design a system. ;)

9. Coding clearly

Syntax consistency

Legibility of the code is crucial for collaboration between programmers. Even for collaboration between yourself and your 2-months-in-the-future self.

That's why adhering to a consistent syntax is important.

People tend to use linters for this. It's a good, though rigid approach, but in teams of more than 1 dev (😉), it makes sense.

Intent clarity

When a function name, a variable name, or a class name doesn't communicate your intent well-enough, you are required to write comments to clarify your intent.

Think not about comments as text that's part of the code for humans to read.

Rather, think about your code as documentation for humans, that computers can compile.

10. Learning how and what to learn

Being a developer can be a highly intellectual endeavor. As such, your efficiency depends on how well you will learn the concepts surrounding your craft.

In general, I suggest following your intrinsic interests, but if you are focused on Web programming, you might find these things to be useful to learn in more details:

• Encryption such as PKI, and TLS more precisely
• Data compression
• Basic protocols such as TCP/IP, HTTP and WebSocket
• DNS
• Technical SEO
• Security in general

Also, don't just learn frameworks.

Learn the underlying their underlying technology and design patterns. For every 30% of your time learning frameworks, spend another 70% learning some of its underlying principles and technologies, to have a solid understanding of your stack.

---

Special thanks to:

• my friends Carlos Edmundo and Francis Perron for the proof reading.