That was one reply to my article about testing:
// Detect dark theme
var iframe = document.getElementById('tweet-993411645731991552-756');
...
For further actions, you may consider blocking this person and/or reporting abuse
Great post.
Your observations are strictly related to the Dunning-Kruger Effect.
Thanks for the feedback! Yes, I read about it some time ago but forgot it :) That is definitely related!
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.
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?
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.
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.
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.
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?
It's hard to convince even experienced engineers of this.
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.
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.
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.
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.
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.
Great article, thanks. I'm in the first phase, swimming through a lot of things to learn :)
I think every phase has its value. So enjoy it! My first phase was definitely fun π
Your a really cool dude Jan
Thatβs an unexpected but most welcome compliment to a nerd π€
At this point in my career, I think that I have forgotten almost everything that was useful.
Ah, yes. Good article, I was going to write something like this, but you beat me to it :D
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)
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/...
Thanks for the video link. I had not seen it.
That is a great talk. Thank you Ben.
I have also hear the phases of a developer learning curve described this way:
How true it is I am not sure.
After "making own framework", most probably "framework" comes again because developers realize how difficult it is to write and maintain a well-designed framework.
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!