DEV Community

Cover image for The Three Stages of a Developer

The Three Stages of a Developer

Jan Wedel on November 08, 2018

That was one reply to my article about testing: // Detect dark theme var iframe = document.getElementById('tweet-993411645731991552-337'); ...
Collapse
 
rafalpienkowski profile image
Rafal Pienkowski

Great post.

Your observations are strictly related to the Dunning-Kruger Effect.

Dunning-Kruger Effect

Collapse
 
stealthmusic profile image
Jan Wedel

Thanks for the feedback! Yes, I read about it some time ago but forgot it :) That is definitely related!

Collapse
 
nestedsoftware profile image
Nested Software

This definitely applies to just about all areas of life! I remember when I was learning to play the game of go, there was a point where I kind of thought I knew what I was doing (I was about 5 kyu, which is pretty bad). Now I realize how totally ridiculous that idea was. Plato wrote (quoting Socrates), "I know that I know nothing." That's so true. The more we learn, the more we realize what a gulf there is between what we know and what is out there to learn.

Collapse
 
stealthmusic profile image
Jan Wedel

Well put! Do you think that when you have experienced it once in a field of Knowledge, it will prevent you fall into that trap in another field?

Collapse
 
nestedsoftware profile image
Nested Software

The tricky thing is, I think, that it's easy to get stuck at that level in the middle. For me, go definitely opened up my eyes, and I look at everything, including programming, very differently as a result. Having that epiphany in one field should be transformative, but not everyone actually gets there.

Collapse
 
joshcheek profile image
Josh Cheek

IMO, all three phases have value. That first stage might feel like "what a fool I was", but in a lot of ways, that shit is enlightened! I think the problem comes when one of these approaches is applied, without context, to all problems.

I think it's a mistake to start a project in over-engineered phase, better to try 10 versions of rapid prototyping, and then as you start to get a sense of the problems, potential solutions, and where the risk is and what's worth investing in, bring in that pragmatism to tame the beast before it grows horns. And over time, as the requirements call for it, and only ever after it's needed, bring in that over-engineering (I guess at that point, it'd be just engineering?) And it's also super valuable to be able to scope which approach you take to which feature you're working on, all within the same code base. Risk, volatility, and uncertainty can vary from feature to feature and method to method.

They're all good, the flaw comes when you don't scope them and they get applied to problems they're a poor fit for. It's a gradient, don't invest in volatile code you might want to throw away tomorrow, and don't make a mess in code that's proven it's worth.

Make sure there is always someone smarter than you.

Not a prescription here, because I'm confident this suggestion is effective for many. For me, though, it was a bit paralyzing (I wasn't free to experiment or explore ideas if I wasn't incredibly confident in them, because I was too worried I'd look like a fool). What usually works for me is to always make sure I'm better than I was yesterday. It is valuable to check in and see where everyone else is from time to time, but it's better to rank myself against where I was than against where someone else appears to be. Also, pushing myself into my zone of discomfort. Basically, whatever it takes to stave off complacence and stagnancy.

Collapse
 
stealthmusic profile image
Jan Wedel • Edited

You made some very good points here that first underline that people are different. That why I didn’t put β€œevery developer” in the headline.

Regarding the phases: I still value them as experience but since I work in a large enterprise, 95% of my work needs to be high-quality maintainable code. So there is less room for experiments. However, we still do it from time to time intentionally and time-boxed. And what you describe is actually agile development. You start a small feature, put it out in the field quickly to get feedback and then change and add stuff iteratively.

Regarding the β€œfind someone smarter”: that’s an exceptionally good thing if you are able to compare yourself objectively to older versions of you. But most of the time, I think the β€œfrog slow cooked in a pot” metaphor applies where you are simply not aware of how it if you change and what might be an achievable goal.
I not sure if the bad experience you describe might be the result of a hazardous working environment fueled by seniors and managers that do not understand the value of making
mistakes?

Collapse
 
katylava profile image
katy lavallee

Accept that low redundancy (DRY) leads to high coupling and balance the two

It's hard to convince even experienced engineers of this.

Recognize code smells

Can you say more about this one? I think I recognize when code smells bad, but I'm not very good at figuring out why. Also I don't know if readers who are new to engineering are familiar with the term.

Collapse
 
stealthmusic profile image
Jan Wedel

Yes. I also know experiences developers that occasionally want to introduce a new common library. And might even be OK in some cases but most of the time the coupling issues weight much higher in the mid-term than the DRY benefits.

Regarding the Code Smells: I would recommend you to read β€žClean Codeβ€œ by Robert C Martin. If you have a system like sonarqube for metrics, it will show you smells and recommend a fix. Pretty neat.

Collapse
 
stealthmusic profile image
Jan Wedel

And to make it absolutely clear: Code duplication in one Code base is really a code smell and must be refactored. I specifically talking about DRY at service/systems level.

Collapse
 
katylava profile image
katy lavallee

Well that depends... Having no abstraction is better than having the wrong abstraction. Sometimes it's better to write something two or even three times before refactoring to make sure you get the implementation right. Although yeah... I have rarely seen this in the same codebase.

Thread Thread
 
stealthmusic profile image
Jan Wedel

Yeah, but I would not write something three times in parallel but change and refactor until it’s right. Use git to revert to previous versions.

Collapse
 
pesko_ profile image
Pesko

Great article, thanks. I'm in the first phase, swimming through a lot of things to learn :)

Collapse
 
stealthmusic profile image
Jan Wedel

I think every phase has its value. So enjoy it! My first phase was definitely fun 😎

Collapse
 
edizle585 profile image
Elijah Logan

Your a really cool dude Jan

Collapse
 
stealthmusic profile image
Jan Wedel

That’s an unexpected but most welcome compliment to a nerd πŸ€“

Collapse
 
douglasjreynolds profile image
Doug Reynolds

At this point in my career, I think that I have forgotten almost everything that was useful.

Collapse
 
jaakidup profile image
Jaaki

Ah, yes. Good article, I was going to write something like this, but you beat me to it :D

Collapse
 
ben profile image
Ben Halpern

This is a really interesting post and topic.

I think this is a really good talk that touches on certain of these elements:

(Not strictly related, I just think it loosely addresses some concepts examined here and is generally a good talk)

Collapse
 
stealthmusic profile image
Jan Wedel

Thanks Ben, indeed a great talk!

Fun fact: Chad now works for Microsoft which acquired Wunderlist to become Microsoft Notes. And he indeed rewrote the backend again using Exchange Server :)

Listen to him on SEDaily podacst: softwareengineeringdaily.com/2018/...

Collapse
 
kspeakman profile image
Kasey Speakman

Thanks for the video link. I had not seen it.

Collapse
 
david_j_eddy profile image
David J Eddy

That is a great talk. Thank you Ben.

Collapse
 
david_j_eddy profile image
David J Eddy

I have also hear the phases of a developer learning curve described this way:

  • no framework
  • framework
  • components (or makes own framework)

How true it is I am not sure.

Collapse
 
stealthmusic profile image
Jan Wedel

After "making own framework", most probably "framework" comes again because developers realize how difficult it is to write and maintain a well-designed framework.

Collapse
 
to_mos profile image
𝓣𝓸-𝓢𝓸𝓼

I really love that you wrote an article on this, it has happened about three different times in my life. I had no idea what it was called or if it happens to everyone. Thanks for the article!