What can you only learn from experience as a Dev?
Posted by _lazyLambda@reddit | ExperiencedDevs | View on Reddit | 91 comments
As a mentor for the last year, ive been curious to reflect on what things I could only have learned from my experiences as a developer, and not from some other source (a book, a mentor, conversations with ChatGPT, etc.). For instance, communicating with a differing opinion about a shared development goal (such as how to reduce the number of incidents/bugs).
So what are you confident you would not have learned if not for your particular career experiences as a dev?
BehindTheRoots@reddit
Breaking production and navigating back can only be learned as trial through fire.
lapinjuntti@reddit
Other than sports and physical stuff, everything you do, and everything you in depth understand others do or you can imagine, it is the same for the brain. So from learning point of view, there is no such a thing in software engineering that you couldn't learn otherwise than from experience.
BUT, the issue is that when you are young, you have the idea of what is important, but it is not necessarily the same what will in practice be important.
For example this "building maintainable systems" from another comment.
I think the issue is not that you couldn't learn it from the books. The issue is that when you are young, you don't appreciate the importance of building maintainable systems enough to be interested to learn about it. Only when you start building systems and you discover in practice that the maintenance actually is one of the biggest issues, only now you truly appreciate and start to learn about it.
I learn vast about about maintainability from books, but it took really long time and experience for it to really sink in that why it is important to apply those principles.
anotherleftistbot@reddit
IMO you can’t learn how to build real maintainable systems until you’ve built them and watched how they fail.
You can get clues from books but IMO if you are staying in a place long enough to watch greenfield work become brownfield work and eventually legacy then you are missing out on a lot of wisdom.
If you job hop every 18 months, I understand why I and I support you but I would say that a lot of learning happens in months 19-36 or even -48.
Of course there is upside of seeing more problems, technologies and different projects too.
But I stand by my assertion. The lessons of system and software design stay with you the deepest when you watch your work fail over time.
Windyvale@reddit
This is the hidden damage companies are doing by making engineers shuffle jobs constantly. There will be no next generation of architects. Not enough engineers get to stick around to experience the impact of their decisions over the long term.
BronzeBrickFurnace@reddit
You can gain that experience from seeing other people's decisions when you are maintaining someone else's promo project. Plenty of opportunities to grow compensation and experience if you're willing to take them.
recycled_ideas@reddit
Except you can't.
When you only come in to the consequences of other people's decisions then the lesson you come away with is that the people before you were idiots who did the wrong thing.
When you face the consequences of your own decisions you realise that there is no 100% right thing. That no pattern will magically make it all work perfectly and that you're trying to predict the future and that you'll get it wrong sometimes.
That connection between a decision that was right at the time and a mess is a critical lesson that you just don't learn if you don't see the decision being right at the time. Instead you just "learn" that you're genius and everyone else is stupid.
lapinjuntti@reddit
That is only about how you approach it.
If you think other people are idiots, you are going to see that everywhere. If you think other people are smart, you are going to see that everywhere as well and you are going to figure out that the decisions they made with the information that they had were probably totally right and good decisions.
Now you have more and different information which may make the decision now a different one.
When you collect this experience from many cases, you can very well learn and see patterns.
Learning only by your own experience is actually among the most inefficient methods to learn.
Indeed sometimes you need to see things in practice to truly appreciate them, but you don't need to make every mistake yourself. If your attitude is right, you can learn great deal from others.
BronzeBrickFurnace@reddit
If your first thought is the other person is a moron and not any empathy for the technical requirements, timelines, etc they were operating under, I'm sorry but must be a new grad or hardstuck IC4 with those terrible soft skills.
recycled_ideas@reddit
Even here you're missing the damned point. You're viewing the decision as wrong but understandable, but that's not always or even often the case.
The difference between a right and wrong decision is how your app and its requirements change in the future. As developers we try to guess how the requirements of an app change and we get it wrong sometimes.
Just_Information334@reddit
Problem is: maintenance is not how you grow your paycheck. Green field projects is how you do.
anotherleftistbot@reddit
Other people’s bad code doesn’t teach as much as your bad code.
“Who wrote this crap!?! Oh… I did… 8 months ago….”
XenonBG@reddit
There will be a next generation of architects but they'll be shitty architects.
CpnStumpy@reddit
Or, hop jobs to become a maintainer and improver of legacy systems for a while. You can absolutely job hop and live in brownfield learning a lot of shit to never do, like writing loops nested in ifs nested in loops nested in cases ... With 1400 line functions.
Refactor that shit without breaking anything because it's got paying customers and learn techniques that do work to next time use instead of the mess
MrJesusAtWork@reddit
How do you avoid beating yourself up for it though?
I'm approaching a time where I need to hand over one project that I've built myself to another team and when they find some issue or design decision that could be better I'm always thinking to myself how could I let these slide at the time.
anotherleftistbot@reddit
Therapy.
Everyone who ever accepted someone else’s code had a 🤦♂️ moment.
Don’t beat yourself up. Get better.
MinimumArmadillo2394@reddit
I was at a job recently where one of the first employees at whatsapp agreed to mentor me.
The company then terminated my employment claiming I wasnt good enough.
I was there for less than 30 days lol
anotherleftistbot@reddit
What was the point of this story?
30thnight@reddit
The thing is that these lessons
are less valuable than the growth and earnings of switching companies every two years (specifically devs under 6-7 years of experience)
can be learned vicariously, if you really care to dive into legacy codebases.
Coldreactor@reddit
Truly some of the best things I've learned over my past 5 years at my job have come from working on new projects over and over again.
There's nothing better than learning from experience how to architect, create and maintain a system.
My first project I had to do? Essentially unmaintable and to this day I'm surprised it still functions.
My latest projects? Maintainable, extensible, and testable.
But I'm eternally thankful for my current job as it lets me, architect and implement multiple greenfield projects a year, while still having to maintain older projects.
diablo1128@reddit
I 100% agree, but you can also stay at a job too long.
I stayed at my first job for too long, 15 years, and never saw any of the upside of changing jobs by seeing more problems, technologies and different projects. I just didn't know any better working at non-tech companies in non-tech cities.
It probably made me a worst SWE that is not valuable to most companies. There is probably a "goldilocks zone" where you can have the best of bother worlds.
anotherleftistbot@reddit
4-6 years.
I've been with my company for too long as well but I keep getting promoted, new responsibilities, more teams, etc.
I'm likely too specialized in some facets but thankfully I have worked on lots of greenfield work in new technologies and my stack is somewhat relevant.
But, I feel your pain.
tehfrod@reddit
Task estimation, library evaluation, when to stop optimizing or polishing.
blad3runnr@reddit
Any recommended reading on the first? Something I need to get better at
David3103@reddit
The question was literally "What can you only learn from experience?"
blad3runnr@reddit
Yes, but some things maybe need priming. Found the code complete book helpful in that regard at least.
mmahowald@reddit
Caution and wisdom
ImprovementMain7109@reddit
That "done" isn't done until code is running in prod and you're watching it misbehave in ways no spec mentioned. How to push back on vague requirements and quietly renegotiate scope without starting a fight. And that most of the job is reading messy code, not writing clever new stuff.
bwainfweeze@reddit
If we ever figure out some post-agile development process, one of the biggest problems it will have to solve to be taken seriously is this one. How do we adjust the development process to incentivize people to stay with a story until it has survived in production through feature toggles becoming permanent and then deleted?
ImprovementMain7109@reddit
Yep, until teams truly own their stuff in prod and on-call, process tweaks are lipstick.
ZunoJ@reddit
How bad most people are at understanding logic connections, that involve a couple steps, and how much you will have to dumb it down
kaisean@reddit
Here's one thing I've learned.
Don't ever depend on another team to build a feature that your team needs me. It might work if the other team is within your same organization (skip manager), but if you're asking some other team that has no innovation to help you, forget it; they'll never do what you ask.
ithinkiboughtadingo@reddit
Realizing that every techincal problem is fixable. Unless you're in some bleeding edge R&D role, just about everything you're building has been built before. There IS an answer out there, you just have to calm down and find it.
On the flip side, realizing that your technical choices rarely have zero human consequences. Over time you learn what they are or could be and hopefully gain some wisdom on how to weigh them.
bwainfweeze@reddit
Reversible decisions are comparatively so easy to fix that you shouldn't even waste the social capital necessary to get consensus on which version to try. Pick something and move the fuck on.
Just be damned sure what you're looking at is a reversible decision, and delay the irreversible ones to the Last Responsible Moment when you have the most information you can afford to have before you have to act. (see also Build Things That Don't Scale - delay asking questions you can fake while answering the ones you can't)
Hotfro@reddit
100% it’s always about tradeoffs and how much time u can spend
kevinossia@reddit
The consequences of your actions.
Which is why job-hopping is a career-killer long-term. You need to build a system from scratch, deploy it, watch it work or not work, and let it run for years on maintenance before you can actually learn how well you did.
You can't do that without sticking around at a job for several years and watching things pan out.
bwainfweeze@reddit
If you're really good at root cause analysis and code forensics, it is possible to ask enough questions to sort out how the mess you're responsible for cleaning up now happened.
You can learn the consequences of other peoples' actions and then apply them to your own decisions. I used to think that was something anyone in software could do. It's probably more like 20%. Maybe 10.
At one point in my early career I claimed jokingly something like that I had 8 years of experience in 6 years, instead of 1 year six times, because I'd worked on everything from green field to maintenance and studied the project history on all of them.
kevinossia@reddit
Indeed. But there’s something different about building the thing yourself and watching it stay standing. Or being on the hook for fixing it. Under tight deadlines. lol.
bluetista1988@reddit
I know someone who's built quite a career on pure greenfield job-hopping. He secures himself a Head of Engineering role at a startup, hires a bunch of people to get from an abstract idea to a production system and then dips for the next one.
Personally I've always preferred to stick around at places. It depends on the company/domain/etc but IMO at mid-large companies you need at least four years there.
thomas_grimjaw@reddit
Pushing back and being aggressive in it.
In the end, like any engineering job, if it can't fit in 7-8 hours per day, then it can't fit and that's that, start damage control.
Basting_Rootwalla@reddit
For me and perhaps more startup or greenfield specific, although useful in product sense period:
The balance of minimal, sloppy, fast solutions to drive tighter feedback loops on end user experiences and/or product market fit+PoC because business is first before engineering, but also laying foundations to transition prototyping into sound engineering designed for the typical scalability, maintainability, and observability.
We're often tested on engineering aspects and in an established project, there is already a foundation set usually to improve upon and adhere to, but if you've never done early startup or greenfield work, you'll miss out on how important learning and understanding business priority and product sense is.
After all, we're building things professionally to for other people to use. Once things operate at larger scale, all of that is offloaded to PMs etc... but in my experience, a good IC who also understands the business aspects can be immensely impactful, just the same way as we can't stand an EM who has no coding experience.
DrapesOfWrath@reddit
The meritocracy is a lie. Developers are low status laborers, that’s why the work gets shipped off to low cost countries.
Early in my career I thought it was a matter of just being good at the job, and then you’d rise. The better you are at your job, the more likely you are to be kept there. With as little pay increase as you’ll tolerate.
Hotfro@reddit
Communication (soft skills), collaboration (designing scalable and working systems + working with cross functional folks), leading projects, delegating work, mentorship
reddit_man_6969@reddit
Never release on a Friday
tehfrod@reddit
Unless you have very good automated rollback capabilities.
stevefuzz@reddit
Lol. Found the over eager manager!
tehfrod@reddit
Manager? I work for a living! 😂
JuanGaKe@reddit
Unless number 2: nobody cares about "that" not working, which should make you think: why in the world I really want to deploy
tehfrod@reddit
That's the first step in turndown for a no-longer-used service: the "Scream Test", when you turn a service off for an hour and see who screams because they've been depending on it without your knowledge
JuanGaKe@reddit
Right! Only problem is the "delayed scream" that only triggers after days, not hour(s), but you simply have to have enough days planned :)
tehfrod@reddit
Yup. Been there, done that, wrote the postmortem.
supercoach@reddit
How to reject work. Saying no is something that people are afraid to do at times.
Mission_Cook_3401@reddit
Troubleshooting
Cube00@reddit
As a delivery driver customers were happy to see me, as a dev the business are never happy to see me.
Epiphone56@reddit
Volunteer to take on investigations for high priority support tickets. Get involved with production releases and then start getting into resolving live issues. That will battle harden you to be able to think on your feet in high pressure scenarios, and is a valuable skill.
Main-Eagle-26@reddit
All the interpersonal stuff, which is inarguably the most important, esp for career success.
Epiphone56@reddit
Yes, definitely. I wanted to go the leadership path in my longest perm role, and got sent on a few courses, with a bit of self study. It's an entirely different skill, but an important one that can be applied even if you're back in an IC role, as I am now.
Stargazer__2893@reddit
How to negotiate with product about what's reasonable to deliver.
KrakenBitesYourAss@reddit
Architecture
bluetista1988@reddit
It blows my mind that some places will interview junior to intermediate candidates on system design and architecture questions. Sure they can regurgitate something about lambdas, AMQP, retries, etc at you but they sure as heck don't understand it in any depth.
rayfrankenstein@reddit
If you haven’t been a developer, you cannot be an effective scrum master or engineering manager.
It’s a sad tragedy that anyone who has never been a professional dev can ever been able to land a job as a professional scrum master.
Until you’ve done the work, you don’t know enough about the work to manage the work being done. This goes for any kind of job.
bluetista1988@reddit
I've had non-technical EMs who were solid EMs, but they absolutely need to be aware of that fact and need at least one really strong senior dev who they can defer to with technical decision-making.
ham_plane@reddit
Just how complex even seemingly simple stuff is, once you dig into it. It gives you a healthy appreciation
bluetista1988@reddit
It's funny to me when non-technical friends complain about sites, apps, or games saying "oh why don't they just do XYZ it would be so simple and they could...." and give a wildly misinformed + oversimplified explanation of it. I don't claim to have all the answers but I feel like I know enough to envision why it might be complicated.
drunkandy@reddit
A total rewrite is almost never the right approach to a problem
bluetista1988@reddit
Essential reading: things you should never do
touristtam@reddit
If you are being paid to create a piece of software: Let go of all ownership of the code. Once written and deployed in production, you'll have stewardship over it at best.
RicketyRekt69@reddit
Learning new programming langauges, tech stacks, etc. is something that becomes easier over time, but writing clean code and architecting something that is scalable can only be learned from experience.
Cute_Activity7527@reddit
How to handle failure.
galacksy_wondrr@reddit
Elaborate?
await_yesterday@reddit
well, it's a lot to
.unwrap()PerceptionDistinct53@reddit
I think there's nothing much other than the feeling of pain after living through it. I have read a lot about incidents, I knew in theory how things can go wild. But living through them now I also know that they can happen to me (software I maintain) as well - which somehow puts a different perspective on.
JorgiEagle@reddit
Why using popular third party solutions is sometimes better than using in house home grown solutions.
Case in point, my current team use a custom implementation of subversion as a VCS. Not Git.
It took me a year to learn, and is difficult to use additional features because there are no examples to learn from, no one to ask, and the documentation is incomplete because it’s in house and the devs are lazy.
You don’t realise how bad it is until you suffer through it
OneCosmicOwl@reddit
Estimations
afty698@reddit
Which corners you can cut and which you can’t.
Steely1809@reddit
Culture fit at companies is a real thing. See all the ex-Amazon people struggling to fit in at new companies.
throwaway0134hdj@reddit
That communication skills are of far greater importance than tech skills. You start realizing it’s not about doing technical stuff for the sake of it, but about solving people problems. And so much can be shaked out by just having in-depth conversations with your team-lead and PM. It actually makes the tickets way less complex and even find out there were mistakes in or that ticket didnt even need to exist because it was already taken care of.
There were countless problems I ran into by simply taking on work and asking no questions and just assuming the person issuing the ticket had it all figured out. It’s so important to understand the business domain too, and getting better insight into how your company generates revenue because that dictates so much about your work.
You realize this job is way less about tech and more about elucidation techniques to clarify requests and seek out the right information - this can save you weeks of headaches just knowing how to ask the right questions and get information.
DeterminedQuokka@reddit
What to do when production goes down
No-Economics-8239@reddit
None of the hard lessons I've learned are easy to communicate to those who have no context or frame of reference to make it easy to relate. Knowing your audience and being a good communicator certainly helps, but there are always limits.
That visceral fear of realizing you just borked production? The knowledge and understanding that you are now in the hot seat, regardless of if you caused it. Hearing the Imperial March blaring from your phone in the middle of the night because pager duty has escalated up to you? Fessing up to mistakes and moving beyond ego to forge something passing as victory from defeat. Finally discovering what rate limits are for or how best to fine tune backoff strategies. Learning the boundaries around arguing about naming things. All those finicky bits of architecture that you don't need to worry about until you scale up to it. The wisdom in keeping your mouth shut or opening it. The need to unwind and refresh and what works best for you to vent and regain your chill.
false79@reddit
General awareness around inefficiency.
Absolutely hated learning DS&A. And I almost never explicitly hand code or given how many libraries put there optimize it call something that is already optimized.
But in day to day life, home and at work, DS&A learnings help apply to non coding things. Soft stuff like what can make this meeting more effective, what tasks do I do that I can automate, how to carve time out of the day or week to get better e.g. 80/20 rule where 20% of time is used to improve the 80%
r_vade@reddit
Sometimes your net output is zero and it’s okay. Early in my career a coworker spent 3 months building an advanced feature into our product. However product had overall stability issues putting shipping at risk, so leadership decided to cut a bunch of features including this particular one. The coworker then spent 3 weeks pretty much undoing everything they’ve done, to no fault of their own. As a result, they ended up spending 4 months with zero output, the product shipped successfully, the coworker was fine and worked at that company for years after that.
bluetista1988@reddit
Some companies would fire that person as a "low performer" for not shipping enough, or not having enough impact on the bottom line.
edwardsdl@reddit
I immediately thought, “well that’s a PIP”. So glad to be out of that bank.
bluetista1988@reddit
Sometimes the best move is no move at all, but nope line must go up.
Esseratecades@reddit
The job isn't about code, but code being smelly or difficult is a good sign that you're solving the wrong problem. The engineering part is figuring out the right problem to solve. Once you've picked the right problem the solution is just a matter of course.
beachguy82@reddit
There’s nothing you learn as a developer or manager you couldn’t have learned elsewhere but the things that I yearned through the career are patience and the ability to know that no matter how much I do know, it’s really just the tip of the iceberg.
Dependent-Guitar-473@reddit
how to your code would scale... any design dession and it's long term impact and how it can scale or not .. this goes for front end, backed, and db .
you can learn how things work, only experience teaches you what doesn't work
anotherleftistbot@reddit
I agree and made a similar point.
StefonAlfaro3PLDev@reddit
X12 EDI
unconceivables@reddit
The bane of my existence.
Sad-Salt24@reddit
The biggest thing I’ve learned from experience is that the "real job" is rarely the code itself. You can read every book on clean architecture, testing, design patterns, but it still won’t prepare you for the moment when two seniors disagree on the right direction, and you’re stuck in the middle trying to move the project forward without stepping on toes.
Another one: understanding tradeoffs in your gut. You only develop that when you’ve shipped something under pressure, made a call, and then lived through the consequences months later. That’s when "simple" and "maintainable" stop being buzzwords and start becoming survival instincts.
And last one, learning how to communicate uncertainty without sounding clueless. That skill didn’t come from tutorials; it came from screwing up a few times, owning it, and realizing nobody cares about perfection as much as they care about progress.
Experience basically teaches you everything between the lines that documentation never covers.
scragz@reddit
troubleshooting