[johnwheeler]

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...

[scarface74]

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-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.

[wwweston]

> How do you know that what you are doing is a “mistake” if it works?

It's a good question, one that's a good nod towards the principle that you will inevitably learn more slowly if your own mind is the only one you have to work with (and lately I've been thinking about how I can get in a professional position where I'm near the bottom end of the intelligence and/or domain knowledge range in the room for this very reason).

But one answer might be: you'll know. "Works" is shorthand for satisfying a certain set of expected conditions. There's a core of reliable behavior in the software that's the minimal working definition of "works" ... but there's also the question of relative ease when it comes to reading, understanding, and changing/augmenting the code you have, or how the code "works" as an expression of the system for the purpose of presenting an interface to the developer.

Chances are pretty good you know the feeling of writing something that you either (a) are uncertain is really adequate as far as the developer experience goes or (b) you know is probably not adequate but seems to get you to the minimal definition of "works" fastest.

Listen to that feeling. Interrogate it. Try something different. Observe the tradeoffs.

[patrickthebold]

I'd argue it's not a mistake if there are no visible consequences.

If you get a production bug that takes a week to fix because the code is a mess you feel it. If adding simple new features is a pain, you feel it.

Now, of course, you might want to skip that, by learning from others, but OP is suggesting that you make your own mistakes.

[scarface74]

It is a "mistake" as soon as the work gets to be too much for one developer and the company brings in some more developers.

By this time, that one inexperienced developer gets promoted to "Architect" because he knows where all of the bodies are buried. Now one of two things happens. He brings in more inexperienced developers because he doesn't know what a good developer is and they keep adding on to the UserManager class and to organize it better, they add section breaks. The class grows.

If they are lucky, they get an experienced developer who tries to tell the "Architect" about proper coding techniques, management and the architect dismisses the critique as "if it ain't broke don't fix it"/"this is the way we've always done it". All of the good developers leave and you are left with only bad developers.

Then you end up with the "Dead Sea Effect"....

http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...

[johnwheeler]

> How do you know that what you are doing is a “mistake” if it works?

Because it hurts.

[scarface74]

So even if you see that your 10K line UserManager class is hurting your velocity and you are spending more and more time maintaining your AcmeDatabaseManager and AcmeLogManager, you still don't why it's taking longer or what to do about it.

[oneplane]

Neither did the first person to encounter it, but they figured it out anyway. There is no magic one-size-fits-all process for this.

[scarface74]

What are the chances that you are as smart as the people who figured it out decades ago?

[oneplane]

Problem solving doesn't work like that. Many comparable issues have been found and solved by different people at different times, in parallel, unknown to each other.

With as many people as we have on Earth it is unlikely that one special unique problem can only be solved by one special unique person. While it might happen, it's unlikely to happen to a software developer at a small company. The problems and solutions you find there are often relatively comparable or even generic, and are found and solved by many people in parallel at the same time. While working together might be faster, it has nothing to do with the feasibility of detecting and repairing issues.

[stcredzero]

That really doesn’t help. How do you know that what you are doing is a “mistake” if it works?

Keep looking at it and ask if you are doing something redundantly.

The only feedback you get as a sole developer are your compiler and errors in production.

False. There's plenty of resources online. There's plenty of code to read online. There's plenty of potential critics online.

You would never know that it isn’t a good idea to write your own AcmeDatabaseManager or AcmeLogManager.

Unless you've read the Internet. There are plenty of database and log utilities out there.

[elamje]

You're going to want to follow the best practice, that no file should be longer than 2 lines of code. One line for imports/requires. One line for a massive one liner.

[anonytrary]

You've triggered my PTSD with the phrase "UserManager class". Seriously, OOP can be such a foot-gun sometimes. Dozens of wrapper classes and manager classes might be the sign of a cluttered mind.

[mindcrime]

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.

[badpun]

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]

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

[sbov]

Reminds me of other comments on this subject: one person's best practice is another person's bad practice.

[scarface74]

I wrote some really long functions in C back in the day just to avoid the overhead of function calls. Yes, this was after running a profiler and we had massive amounts of data (for the time) to crunch within a short window.

[peller]

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.

[PaulHoule]

If you have a 10k line UserManager class and you are happy with that, than that is fine.

If the 10k line UserManager class has you pulling your hair out, you know you have a problem.

[jaclaz]

In one sentence (by C.S. Lewis ):

“Experience: that most brutal of teachers. But you learn, my God do you learn.”

[beat]

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]

Relevant:

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-e...

[braindouche]

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?

[mindcrime]

What does this look like in practice?

My interpretation of that has always been something like "repeating the same actions over and over again, but never importing any new knowledge from outside" where "outside knowledge" means books, classes, blog posts, videos, meetups, etc. So you can "learn" to just keep doing the same thing incrementally better by just doing it the way way for 10 years, but to make significant changes, you need whole new models, thoughts, and ways of seeing things.

Now sometimes you may make a big leap purely off introspection, applying logic, empirical experimentation, etc., but that would - IMO - be an exception for most people.

[vokep]

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]

Sometimes there is a mismatch between seniority and experience.

[Fezzik]

“One year of experience ten times” is shorthand for repeating the same banal tasks over and over and never increasing your skillset. Versus “ten years of experience”, indicatig 10 years of varied tasks, increased responsibility, increasing your skillset etc...

[jasonlotito]

One definition: A developer who joins a team, builds out a product, and then leaves for a new job after a couple years. They don't stick around long enough to see their code become legacy, and then get replaced.

[jb3689]

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]

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]

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.

[everdev]

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]

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.

[hprotagonist]

5. Ideally, make _unique_ mistakes.

[reaperducer]

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.

[bch]

> ...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”.

[sawmurai]

Haha, I like that.

[stcredzero]

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.

[mrskitch]

++ 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 :)

[127]

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]

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.

[satokema_work]

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.

[_e]

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

[lerax]

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

[wolco]

repeat for new languages