6 ms·

1. Make lots of mistakes. 2. Experience pain in the form of late, buggy software and angry clients. 3. Read books and work on side projects. (Martin Fowler’s

1. Make lots of mistakes. 2. Experience pain in the form of late, buggy software and angry clients. 3. Read books and work on side projects. (Martin Fowler’s were my favorite). 4. Repeat for 5-10 years with hopefully ever-decreasing amounts of 1 and 2. You probably think I'm kidding...

wolco 8y ago
repeat for new languages
satokema_work 8y ago
There's no substitute for direct experience. You can rattle off quotes and documents all day, but this doesn't teach 1% as much as the direct pain of dealing with st on the job.
hprotagonist 8y ago
5. Ideally, make _unique_ mistakes.
- reaperducer 8y ago
  I had a boss once who called them "errors of enthusiasm," as long as they only happened once. If you made the same mistake twice, then you were in trouble.
  - sawmurai 8y ago
    Haha, I like that.
  - bch 8y ago
    > ...as they only happened once. If you made the same mistake twice, then you were in trouble. I guess I’d be worried about classifying. “Play” part of discovery might have multiple cases of (nearly) identical “mistakes”.
jaclaz 8y ago
In one sentence (by C.S. Lewis ): “Experience: that most brutal of teachers. But you learn, my God do you learn.”
- beat 8y ago
  Hopefully. A friend of mine once said "So do you have ten years of experience, or do you have one year of experience ten times?"
  - dsego 8y ago
    Relevant: How Developers Stop Learning: Rise of the Expert Beginner https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://daedtech.com/how-developers-stop-learning-rise-of-th... How Software Groups Rot: Legacy of the Expert Beginner https://daedtech.com/how-software-groups-rot-legacy-of-the-expert-beginner/ https://daedtech.com/how-software-groups-rot-legacy-of-the-e...
  - braindouche 8y ago
    I've heard this old saw a million times, or maybe once a year for a million years, but what does it really mean? Nobody seems to be able to describe to me a developer with one year of experience ten times. What does this look like in practice?
    - vokep 8y ago
      someone who despite having been in the industry many years, has only learned more and more jargon, but not technical skills. So they sound almost like the experience they have counts, except when you put them next to someone with the same level of experience and stronger understanding, the difference is obvious.
      - jaclaz 8y ago
        Sometimes there is a mismatch between seniority and experience.
    - 8y ago
everdev 8y ago
This is the dirty secret of tech. We're almost all self-learning all the time. By the time it becomes more of a formula than an art, it'll be automated.
smoe 8y ago
This I think makes the difference between people who follow "best practices" and people who understand why they apply certain practices or not dependent on the situation.
jb3689 8y ago
This. I have been looking for a company to be mentored at for the past 8 years. They don't exist (well they do, but they are few and far in between - and it varies from team to team even in a company) The way I've learned is through books/talks, common sense (often things are clearly terrible for obvious reasons), people willing to take risks on giving me projects, and sweat/mistakes/learning how to focus on the right things through experience
- radicalbyte 8y ago
  They do but they're extremely rare. Before I started for myself I spent a lot of time mentoring my team. Most if it was building their confidence up so they could think critically themselves whilst reading the right books. I myself have never had a technical mentor. Never needed one. What I did need and have were mentors for the other 90% of being a successful professional (and people who built my self confidence up).
  - jamestimmins 8y ago
    I think this is because "mentorship" is very hard to plan at the company level. My best mentors have been specific senior devs who were willing to share what they knew.
mrskitch 8y ago
++ to this. Experience is the best teacher, though I think it widely depends on the person learning. Some individuals will learn well from others' whereas others really need to feel the fire to know why it's hot. This, of course, coming from a person with burn marks :)
scarface74 8y ago
That really doesn’t help. How do you know that what you are doing is a “mistake” if it works? 10K line UserManager classes “work”. That’s how you get the “expert beginner”. https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://daedtech.com/how-developers-stop-learning-rise-of-th... The only feedback you get as a sole developer are your compiler and errors in production. You would never know that it isn’t a good idea to write your own AcmeDatabaseManager or AcmeLogManager.
- mindcrime 8y ago
  How do you know that what you are doing is a “mistake” if it works? Reading. Plenty of books, blog posts, and forum posts point out that you shouldn't have "10 KLOC UserManager classes". The thing is, one has to figure out how to integrate "book learning" AND real world experience, so that they're constantly synthesizing a newer, better understanding.
  - peller 8y ago
    Yes. I would also include reading other more-experienced developers' code in bullet point #3. Pick a well-respected project from a language you're looking to get better at, and dive in.
  - badpun 8y ago
    Funny thing is, if you look at codebases of some opensource projects [1] doing complex and ambitious stuff, written by some real experienced engineers, you’ll see the common „dogmas” (don’t have long classes, don’t have long methods etc. etc.) are not obeyed. And yet, they shipped very complex and successful software. It’s almost as if these rules are mostly arbitrary and don’t really matter. [1] I’ve noticed that in codebases of Apache Spark, Apache Oozie, Apache Cassandra, and Firefox.
    - mindcrime 8y ago
      It’s almost as if these rules are mostly arbitrary and don’t really matter. Definitely. I mean, some of them probably have some objective basis. But clearly some of them are indeed subjective and arbitrary. Take "long method names" for example... I believe method names should state what they do, and should be however long it takes to do that. To my way of thinking, making a method name shorter just for the sake of being shorter, and eliding semantic information, is an anti-pattern, not a best-practice. shrug
stcredzero 8y ago
1. Make lots of mistakes. It's all about hundreds of cost/benefit trade-offs in a particular context. There will be trade-offs between short, medium, and long term goals and issues. There will be trade-offs between the developers, management, sales, and the users. Try to find as many compromises as possible which are synergistic. When it comes to hiring and otherwise interacting with other coders, you will even make compromises with the developer community! 4. Repeat for 5-10 years At least. Always be learning from your mistakes. Be skeptical of yourself and your own model of reality. You should be actively looking for your biases and misunderstandings. Try to understand where the contrarians are coming from. If they have a point, it just might be valuable. Be wary of dogmatism.
lerax 8y ago
Actually this it's a good advice. For me 5 years worked.
127 8y ago
It's curious that for my first software enterprise I'm already doing those things. It's a lot of A. just starting, B. pushing through pain, C. keep pushing. Strangely, there have been very few customers who have been unhappy. Many have even written long glowing reviews that have had a great positive impact in profits. Those who give negative feedback seem to always have a problem or a pain. Being kind of a bloodhound to discover what that pain is and where did it come from seems very valuable. Two most difficult things for me seem to be: A. drawing borders and limits on my time and what to do and when to say no, B. pricing They say just surviving long enough mean you win, but turning a business to make profit seems really a herculean task, even as a solo dev.
allochthon 8y ago
I'll just add that good, maintainable software is as much about communication with other devs, in the form of code that they can read without being too distracted, as it is about getting the immediate job done. That requires socialization with other software developers on some level. That kind of socialization is going to be harder for a lone developer to obtain. But I imagine working on an open source project where there are other people will do the trick.
_e 8y ago
Experience is what you get when you don't get what you want.

wolco 8y ago

repeat for new languages

satokema_work 8y ago

There's no substitute for direct experience. You can rattle off quotes and documents all day, but this doesn't teach 1% as much as the direct pain of dealing with st on the job.

hprotagonist 8y ago

5. Ideally, make _unique_ mistakes.

reaperducer 8y ago
I had a boss once who called them "errors of enthusiasm," as long as they only happened once. If you made the same mistake twice, then you were in trouble.
- sawmurai 8y ago
  Haha, I like that.
- bch 8y ago
  > ...as they only happened once. If you made the same mistake twice, then you were in trouble. I guess I’d be worried about classifying. “Play” part of discovery might have multiple cases of (nearly) identical “mistakes”.

jaclaz 8y ago

In one sentence (by C.S. Lewis ): “Experience: that most brutal of teachers. But you learn, my God do you learn.”

beat 8y ago
Hopefully. A friend of mine once said "So do you have ten years of experience, or do you have one year of experience ten times?"
- dsego 8y ago
  Relevant: How Developers Stop Learning: Rise of the Expert Beginner https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://daedtech.com/how-developers-stop-learning-rise-of-th... How Software Groups Rot: Legacy of the Expert Beginner https://daedtech.com/how-software-groups-rot-legacy-of-the-expert-beginner/ https://daedtech.com/how-software-groups-rot-legacy-of-the-e...
- braindouche 8y ago
  I've heard this old saw a million times, or maybe once a year for a million years, but what does it really mean? Nobody seems to be able to describe to me a developer with one year of experience ten times. What does this look like in practice?
  - vokep 8y ago
    someone who despite having been in the industry many years, has only learned more and more jargon, but not technical skills. So they sound almost like the experience they have counts, except when you put them next to someone with the same level of experience and stronger understanding, the difference is obvious.
    - jaclaz 8y ago
      Sometimes there is a mismatch between seniority and experience.
  - 8y ago

everdev 8y ago

This is the dirty secret of tech. We're almost all self-learning all the time. By the time it becomes more of a formula than an art, it'll be automated.

smoe 8y ago

This I think makes the difference between people who follow "best practices" and people who understand why they apply certain practices or not dependent on the situation.

jb3689 8y ago

This. I have been looking for a company to be mentored at for the past 8 years. They don't exist (well they do, but they are few and far in between - and it varies from team to team even in a company) The way I've learned is through books/talks, common sense (often things are clearly terrible for obvious reasons), people willing to take risks on giving me projects, and sweat/mistakes/learning how to focus on the right things through experience

radicalbyte 8y ago
They do but they're extremely rare. Before I started for myself I spent a lot of time mentoring my team. Most if it was building their confidence up so they could think critically themselves whilst reading the right books. I myself have never had a technical mentor. Never needed one. What I did need and have were mentors for the other 90% of being a successful professional (and people who built my self confidence up).
- jamestimmins 8y ago
  I think this is because "mentorship" is very hard to plan at the company level. My best mentors have been specific senior devs who were willing to share what they knew.

mrskitch 8y ago

++ to this. Experience is the best teacher, though I think it widely depends on the person learning. Some individuals will learn well from others' whereas others really need to feel the fire to know why it's hot. This, of course, coming from a person with burn marks :)

scarface74 8y ago

That really doesn’t help. How do you know that what you are doing is a “mistake” if it works? 10K line UserManager classes “work”. That’s how you get the “expert beginner”. https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://daedtech.com/how-developers-stop-learning-rise-of-th... The only feedback you get as a sole developer are your compiler and errors in production. You would never know that it isn’t a good idea to write your own AcmeDatabaseManager or AcmeLogManager.

mindcrime 8y ago
How do you know that what you are doing is a “mistake” if it works? Reading. Plenty of books, blog posts, and forum posts point out that you shouldn't have "10 KLOC UserManager classes". The thing is, one has to figure out how to integrate "book learning" AND real world experience, so that they're constantly synthesizing a newer, better understanding.
- peller 8y ago
  Yes. I would also include reading other more-experienced developers' code in bullet point #3. Pick a well-respected project from a language you're looking to get better at, and dive in.
- badpun 8y ago
  Funny thing is, if you look at codebases of some opensource projects [1] doing complex and ambitious stuff, written by some real experienced engineers, you’ll see the common „dogmas” (don’t have long classes, don’t have long methods etc. etc.) are not obeyed. And yet, they shipped very complex and successful software. It’s almost as if these rules are mostly arbitrary and don’t really matter. [1] I’ve noticed that in codebases of Apache Spark, Apache Oozie, Apache Cassandra, and Firefox.
  - mindcrime 8y ago
    It’s almost as if these rules are mostly arbitrary and don’t really matter. Definitely. I mean, some of them probably have some objective basis. But clearly some of them are indeed subjective and arbitrary. Take "long method names" for example... I believe method names should state what they do, and should be however long it takes to do that. To my way of thinking, making a method name shorter just for the sake of being shorter, and eliding semantic information, is an anti-pattern, not a best-practice. shrug

stcredzero 8y ago

1. Make lots of mistakes. It's all about hundreds of cost/benefit trade-offs in a particular context. There will be trade-offs between short, medium, and long term goals and issues. There will be trade-offs between the developers, management, sales, and the users. Try to find as many compromises as possible which are synergistic. When it comes to hiring and otherwise interacting with other coders, you will even make compromises with the developer community! 4. Repeat for 5-10 years At least. Always be learning from your mistakes. Be skeptical of yourself and your own model of reality. You should be actively looking for your biases and misunderstandings. Try to understand where the contrarians are coming from. If they have a point, it just might be valuable. Be wary of dogmatism.

lerax 8y ago

Actually this it's a good advice. For me 5 years worked.

127 8y ago

It's curious that for my first software enterprise I'm already doing those things. It's a lot of A. just starting, B. pushing through pain, C. keep pushing. Strangely, there have been very few customers who have been unhappy. Many have even written long glowing reviews that have had a great positive impact in profits. Those who give negative feedback seem to always have a problem or a pain. Being kind of a bloodhound to discover what that pain is and where did it come from seems very valuable. Two most difficult things for me seem to be: A. drawing borders and limits on my time and what to do and when to say no, B. pricing They say just surviving long enough mean you win, but turning a business to make profit seems really a herculean task, even as a solo dev.

allochthon 8y ago

I'll just add that good, maintainable software is as much about communication with other devs, in the form of code that they can read without being too distracted, as it is about getting the immediate job done. That requires socialization with other software developers on some level. That kind of socialization is going to be harder for a lone developer to obtain. But I imagine working on an open source project where there are other people will do the trick.

_e 8y ago

Experience is what you get when you don't get what you want.