I like your article, Tyler. And I love your metaphor, I believe there's some truth to it. But I I've always professed quite the opposite:
An expert is a person who has made all the mistakes that can be made in a very narrow field.
― Niels Bohr
My advice, especially to new developers, is this:
Get out there. Code something. Code anything. Do something ugly. Push it to production. Feel the pain of seeing it falling apart when your first users input some unexpected data or use it in a very, very silly way. Dig your way though the logs. Understand what's going on. Fix it. Make it better. Make it more ergonomic so people use it correctly without you telling them. Repeat the cycle as fast as possible. Accumulate experience.
Development is not like tennis or ping-pong (sorry). It's an art. And there are no straight do or don't out there. Just a bunch of principles and recommendantions that you should always take with a pinch of salt. At the end of the day, those architecture gurus are not there on a late saturday night when you're debugging your app.
While programming is little more than talking to the machine, development is another level. It's a communication, a dance, between machines, people, businesses, structures, infrastructures. It's debatable one can ever find an axiomatic truth about what makes a good software. It's like trying to define once and for all what's good dancing 💃
If you think I'm wrong, then I suggest you write down your findings in a methology book on "How to deliver value with certainty using software." You're a guaranteed billionaire overnight 😂
All that said, I mostly agree with Tyler and just wanted to have some fun here 🙃 Have a good one and follow me if you'd like to know more on how to improve your coding game 😎
I love the Niels Bohr quote and wholeheartedly agree with it and with your summary of it:
Get out there. Code something. Code anything. Do something ugly. Push it to production. Feel the pain of seeing it falling apart when your first users input some unexpected data or use it in a very, very silly way. Dig your way though the logs. Understand what's going on. Fix it. Make it better. Make it more ergonomic so people use it correctly without you telling them. Repeat the cycle as fast as possible. Accumulate experience.
Correct me if I'm wrong, but I think we are definitely mostly agreed here, saying the same thing but in slightly different ways. Trying and failing and gaining experience is a valuable thing. And then, we learn from these mistakes. After feeling the pain of our code breaking in production, we learn these lessons and apply them consistently.
Taking your example, maybe the user entered some unexpected input which broke the app, so now you as the developer have learned that you should write code that can fail gracefully or that can handle bad input. You've learned to write better unit tests (or maybe you didn't write any tests at all! 😱). You've learned to think about more than just the happy path and to think about how things can fail. And hopefully you've documented this knowledge somewhere that you can frequently refer to it so that you don't make these mistakes again.
So in short, through your experience, you learn to stop making the mistakes in which you've previously defeated yourself. You figure out how to play the loser's game.
P.S. I'm not sure if you've ever read Michael Lopp's essay on "Stables and Volatiles", but based on some of the ideas you've expressed I think you would really enjoy it: randsinrepose.com/archives/stables... 😄
P.S. I'm not sure if you've ever read Michael Lopp's essay on "Stables and Volatiles", but based on some of the ideas you've expressed I think you would really enjoy it: randsinrepose.com/archives/stables... 😄
Thanks a bunch, I'll have a look 👀
Correct me if I'm wrong, but I think we are definitely mostly agreed here
You are not wrong. I might add that pain is, IMHO, an essential component of the learning process. Trying to avoid it and staying in your comfort zone is perhaps the worst mistake you can make in that looser's game. One that will surely impede your growth and therefore, your ability to avoid making other mistakes.
A personnal example of mine is that I rejected automated testing until 2017, deeming them worthless and demeaning people who wrote them. Simply because I was afraid of subjecting my work to an objective standard of measurement 🥲
So, beat yourself up as much as you can tolerate 😅 Trust me, the payoff is huge.
I think developers are masochist.
We like the frustration of finding a solution to a problem, or debugging for hours (i mean, i hate it.. i hate that i somehow love it)
But the kick, oh that kick, after the hours of "losing" shots, seeing your artwork in the wild, handling everything users can throw at it...
Yeah. Worth it!
Thanks for the article. It's a good read!
I like your article, Tyler. And I love your metaphor, I believe there's some truth to it. But I I've always professed quite the opposite:
My advice, especially to new developers, is this:
Get out there. Code something. Code anything. Do something ugly. Push it to production. Feel the pain of seeing it falling apart when your first users input some unexpected data or use it in a very, very silly way. Dig your way though the logs. Understand what's going on. Fix it. Make it better. Make it more ergonomic so people use it correctly without you telling them. Repeat the cycle as fast as possible. Accumulate experience.
Development is not like tennis or ping-pong (sorry). It's an art. And there are no straight do or don't out there. Just a bunch of principles and recommendantions that you should always take with a pinch of salt. At the end of the day, those architecture gurus are not there on a late saturday night when you're debugging your app.
While programming is little more than talking to the machine, development is another level. It's a communication, a dance, between machines, people, businesses, structures, infrastructures. It's debatable one can ever find an axiomatic truth about what makes a good software. It's like trying to define once and for all what's good dancing 💃
If you think I'm wrong, then I suggest you write down your findings in a methology book on "How to deliver value with certainty using software." You're a guaranteed billionaire overnight 😂
All that said, I mostly agree with Tyler and just wanted to have some fun here 🙃 Have a good one and follow me if you'd like to know more on how to improve your coding game 😎
Thank you Benjamin for the thoughtful reply!
I love the Niels Bohr quote and wholeheartedly agree with it and with your summary of it:
Correct me if I'm wrong, but I think we are definitely mostly agreed here, saying the same thing but in slightly different ways. Trying and failing and gaining experience is a valuable thing. And then, we learn from these mistakes. After feeling the pain of our code breaking in production, we learn these lessons and apply them consistently.
Taking your example, maybe the user entered some unexpected input which broke the app, so now you as the developer have learned that you should write code that can fail gracefully or that can handle bad input. You've learned to write better unit tests (or maybe you didn't write any tests at all! 😱). You've learned to think about more than just the happy path and to think about how things can fail. And hopefully you've documented this knowledge somewhere that you can frequently refer to it so that you don't make these mistakes again.
So in short, through your experience, you learn to stop making the mistakes in which you've previously defeated yourself. You figure out how to play the loser's game.
P.S. I'm not sure if you've ever read Michael Lopp's essay on "Stables and Volatiles", but based on some of the ideas you've expressed I think you would really enjoy it: randsinrepose.com/archives/stables... 😄
Thanks a bunch, I'll have a look 👀
You are not wrong. I might add that pain is, IMHO, an essential component of the learning process. Trying to avoid it and staying in your comfort zone is perhaps the worst mistake you can make in that looser's game. One that will surely impede your growth and therefore, your ability to avoid making other mistakes.
A personnal example of mine is that I rejected automated testing until 2017, deeming them worthless and demeaning people who wrote them. Simply because I was afraid of subjecting my work to an objective standard of measurement 🥲
So, beat yourself up as much as you can tolerate 😅 Trust me, the payoff is huge.
I think developers are masochist.
We like the frustration of finding a solution to a problem, or debugging for hours (i mean, i hate it.. i hate that i somehow love it)
But damn, it is painful sometimes
Development is indeed an activity we love to hate 😂
But the kick, oh that kick, after the hours of "losing" shots, seeing your artwork in the wild, handling everything users can throw at it...
Yeah. Worth it!
Thanks for the article. It's a good read!
Added some clarification here! dev.to/thawkin3/comment/1iaka