What software development skills only come with experience?

Some fresh-out-of-school grads are really good. Sometimes newer programmers have completely skipped over the hangups more experienced developers have gathered.

I'm often amazed at the skills of newbies.

But there are certain skills that literally can only be learned with experience. Let's talk about those.

Did you find this post useful? Show some love!
DISCUSSION (82)

Being able to challenge the PO's requirements.
I mean: not accepting every demands without any question.
Being able to understand the business needs and feeling comfortable enough to say no when a user story adds no value to the product.

I’m going to hop in and say the opposite is also valuable. Sometimes acceding to the needs of business, a particular customer, or another team is absolutely in everyone’s best interest, even if you can’t immediately figure out what the value is, or the value seems marginal. I know that when I was starting out, I would gripe about seemingly pointless work (and I still do, working on it 😃) where the reality was that costs had been weighed well before I heard about the decision. I think that the intuition to judge whether a given solution is necessary, and whether it is solving the problem being described, is the thing that comes with time.

Yes, you're right. And it also comes with better knowing your team.

This sounds great and all, but you have to play office politics sometimes unfortunately.

Be bold enough to stand against the wrong things even if it's your boss. That's it. You are going to leave your mess for your future self or whoever is going to work on it in the future.

That's it. You must absolutely avoid having an over-configurable app, with features that may be never used because you will have to maintain all of this in the future.

This is the first 3 come to my mind at the moment

  • Being able to make a good estimation
  • Do not take things personally
  • Understand business needs

Yeah, estimation was one of the things I thought of, too—it's definitely something I've gotten a way better sense of with time, especially knowing how much extra time I need to build in for surprises coming up.

8 years, I still can't estimate. I have a feeling at 30 years, I still won't be able to estimate.

In my experience there are only two estimates that consistently matter: "really really easy" and "really really hard." If your Product Manager thinks a task is easy but it's actually hard, you have to teach them so they can decide if it's really worth the effort right now (or at all). If they think a task is hard but it's actually easy, you have to teach them so they can decide if it should be prioritized for a quick win.

Obligatory: xkcd.com/1425/

Almost 20 years in business and still cannot estimate.

Read and ye shall as estimate as well as any engineer who walks this earth. ocw.mit.edu/resources/res-6-011-th...

Two skill areas that come to mind for me:

Risk management

Risk management is rarely by the book. You need to have lived through a lot of good and bad risks in order to have a sense of how to weigh these things.

Productivity

This is fairly broad, but I really think productivity as a developer is a really hard skill to be taught or to have innately. Having an idea of how long a thing is supposed to take and being consistent about spending your time takes experience.

Re: Risk management - There's also the notion that sometimes, it's better to take the risk that something really bad will happen, because trying to mitigate that risk is too costly.

Risk management isn't "Don't do anything that could fail", it's "Choose which things you do based on how likely it is to fail, how bad the failure could be, and how much work it takes to mitigate the risk".

Two things related to productivity is organization of code and writing code that is easily maintainable. These things are not intuitive and don't have a "right" answer but in my opinion you really only get better at by shooting yourself in the foot a few times.

(Mental) Muscle Memory

I think a big part of the reason we associate productivity with senior engineers is their ability to perform common coding tasks from memory in just a few minutes. To adopt a video game analogy: sometimes coding is a metroidvania and the right combination of button presses in the right order can finish up a task really quickly. Other times, coding is a puzzle game, where experience sometimes gives you an intuition for how to solve the problem, and other times sends you running in the wrong direction. Thus the importance of a wide variety of perspectives and experience levels.

Balance

Sometimes a junior engineer comes in fully loaded with Best Practices™, design patterns and other Platonic ideals and becomes disillusioned really fast when presented with the compromises and shortcomings of normal software. If they're unwise, they try to fix everything and make all the code perfect; this is a mistake. Senior engineers generally understand that code isn't perfect--there are things you can do to improve it, but only so much is practical. This lets them optimize for development speed and simplicity, which can be extraordinarily difficult to do without having a few hundred thousand lines of code under your belt.

Brilliant. Love that second point. Just yesterday I downloaded a tutorial R script for something I'm working on and didn't like the way it was styled, so I started changing it.

Now I'm thinking that might be a little over-zealous.

reminds me of my first few months as a dev when I was in a "fix all the static analysis warnings" mode on a project which ended up rewritten from scratch because new requirements didn't fit the old architecture a few months later

"Best Practices™" - I love it !

How to fail fast and properly.

New developers fail like an elephant in a porcelain cabinet. Experienced developer fail like ninjas.

Hi. Your point is interesting but I have a question. How I can fail properly if a company want all works well?

I'm going to finish my career in one year and I want to be a good developer. This community is awesome :)

I think the other thing is to communicate early and often if things are going wrong, and to get comfortable asking others for help. A lot of folks learn to hide when they're struggling, but if you're working with a good team, they'll be able to adjust timelines and get you the help you need if you keep in touch about how you're doing, especially at the beginning of your career. :)

Make failing part of the process. Test Driven Development for example is failing first (all tests fail), then fixing it. Making prototypes is a way to fail early in the process, so when you start to make the real implementation you already tackled various mistakes. Write software in such a way that failures are expected, so that you handle them. Chaos Engineering is good example of this. Write clean code, have useful debug logging, etc. Once something fails, you'll be able to take care of it quickly as it is easy to diagnose and fix.

Even when beginners do all this, it will all be visible. But eventually you do these things with enough grace that it looks like you meant to do it.

Remember, nobody has ever written a perfect program, and you are unlikely to be the first. If a company cannot accept this, then get out!

Ooo I understand. Thanks for your advice

Managing Stakeholders
Sure, some folks might be naturally skilled or able to put academic skills to work dealing with "higher ups" and customers, but imo, there's no true replacement for the experience you get managing your stakeholders.

Risk Management
@ben mentioned this category already, but to expand on his point, I've seen (and been a part of) lots of cowboys and cowgirls who are ready to revamp, refactor, add new features, and push straight to prod. Slooowww down there. 😁

I think the universal thing that comes with experience is (usually) more accurate situational judgement. Because experience likely means you've already tried to solve the problem many different ways. And you've seen which ones don't work or work poorly.

There are some amazing answers given already, but from my personal experience, it's the ability to switch off and move away from your task when you're not working. I always used to think about the problem at work for hours even after coming home. But it's important to give your mind some healthy detox once you're off work and focus on other things!

Also, understanding the fact that senior devs in your team are humans too, and they're also going to make mistakes.

Understanding that code is the easy part. If for 4 years you are praised for technical achievements you start to believe that's all it takes. The reality is 90% of building a software system is everything but the technical stuff.

I woudn't say it only comes with experience,

but debugging gets a lot easier and faster when you've had enough experience with a language to understand where you could have gone wrong (or what exactly error messages are trying to tell you)

Keep it Simple,
As a junior I always felt the need to over engineer my solution,
I always overrated abstraction and Design patterns etc.

With experience the value of Keep things Simple is becoming apparent

I have The Hunch™ :).

It's when the current situation is seemingly good, but based on past experience I suspect there might be a problem.

There usually is.

dev.to/ice_lenor/the-hunch-4-times...

Being presented with a feature/request/idea/whatever and even though it seems to make good ROI sense, good technical sense, and meet every other criteria, that it's a bad idea and will fail in the long run -- because you've seen it happen before.

I can't even think of a good example to illustrate. It's more of a vibe or general unease. I learned recently my boss calls it my "spidey sense" and if it goes off he digs into it with me.

It's Hans Solo's "I've got a bad feeling about this" because he's been there before.

Your boss gets into it with you and you can’t even think of a good example..?

Oh I can think of examples of when my spidey sense went off, but nothing I can share publicly, and nothing I can think of about the situation that would result in any sort of "things to consider." If that makes sense.

Late to the party, but a huge part of programming is pattern recognition. Taking one pattern, tweaking it, and applying it to another problem is so much of code. Experienced developers have a larger repository of those problems mentally built up, so programming is a lot more instinctive.

Also, knowing how to search things well is huge. You can teach it, but it takes a lot of getting used to

  1. Know how to tell buzzwords from things that will actually bring value to your product/company.
  2. Forget about the IDE and have your own toolset.
  3. Being able to say: "Been there, done that, had the drinks, bought the T-Shirt, debugged the code, made a fork"

Is that polemics or did you get your experience from yt videos? 🐣😴😅

I think I was already finishing college when Youtube came out...

I think, that self-organization is something you don't just learn, but rather build up through various iterations.

The same goes for your tools and workflows on your machine.

  • Work with a bunch amount of data
  • Think in situations of error that your code can throw
  • Architecture of your code for future improvements

When you are a newbie and just code in personal projects or in small projects, you don't realize how your code will behave in different situations, just in a few situations. The same thing dealing with memory allocation and database consult.

  1. giving accurate estimations

  2. think first and code second, often newbies tend to start coding immediatly and change their code 3 or 4 times before the final solution, which could be improved with a good solution design before coding

  3. Think of all the "moving parts". With experience we tend to be a lot more thoughtful on what is happening under the hood, where we are using to many cpu cycles, what is our code's ram usage or network traffic for example

I think some things are easier to learn with experience, but I'd emphasize that years of experience !== skill in that area. Say, estimating or giving good feedback - those things are easier to learn with practice, but intentional practice yields better results, by far.

  1. Estimating (points or hours).

  2. Solid Unit Tests for tests that matter. I think "code coverage" becomes an obsession with some devs.

  3. Try to not gold plate everything. Sometimes just get it done.

  4. Don't try and optimise and micro optimise code as you develop from scratch. Get it in a working state, then start optimising.

  5. Dont be afraid to ask, and understand making mistakes is how we learn.

  6. Guinness is all you need on a Friday.

Things you probably won't learn in school:

  • How to organize your code and files well (that scales with large codebases)
  • How to structure solutions on a high-level
  • How to use composition (object or function) as the means of code re-use (you will learn about inheritance instead 😒)
  • How to do real OOP (which is really closer to functional programing than most think)

Aside from that:

  • Real confidence (sometimes you just need to have done X many times)
  • Broad understanding of how front-end can affect back-end, etc.
  • Writing really simple and readable code

From my experience I can say:

architectural insights
I really found a gap between popular algorithms/patterns we learned and their real usage: the reality on the field. It takes some failures to know which is good, which is overkill. Works also for the frameworks you battle-tested and you know they will do the job for this task/project. Also, I learned a few about PHP and NodeJS, but I was still lost on the existential question: which one to choose for web app. Chances are that you can only answer from experience and skill. Same with RDBS vs NoSQL... Untill you tryied it, it will almost always seems fuzzy and you will choose by default instead of by being aware of pros/cons.

Regarding the PHP or nodeJS question: Depends on the ...

P > N Robustness
P < N Rapid Prototyping
P > N If you need reliable object relation models
P < N If you’re more the front end react angular ui developer
...
..
.

It’s you having to decide on a uncountable amount of parameters 🤭

Vocab. The vocabulary in tech is extensive. It affects the conversations you can understand just by context, it affects how efficient you are at finding the right solution through google, it even affects how fast you can convey the issue you're having to a coworker if you want a second opinion.

It's something we take for granted and always feel like we never know enough but it's crazy how much your internal dictionary grows organically with nothing but time and exposure.

I agree with mostly everything that's been said by others, from saying no to stakeholdelrs to being faster at debugging.

Great answers!

I would add this which probably has been said in other forms: knowing when something is good enough, knowing when to stop.

Basically start moonwalking in the other direction when perfection comes knocking

Asking 'Why' until you actually understand it.

You can't persuade people of your ideas for the "right way to go" without experience. You have to earn credibility for this and have to be able to discuss all aspects involved, some of which won't ever get written down.

Citing what you learned at university or the best books available is a weak argument.

When someone wants to learn software development from scratch, there is an overwhelming amount of information in book stores, libraries, and online articles. Experience tells which information is necessary at which stage of the learning journey and which can be postponed.

German below
Most of the time you are in a shitty situation as a programmer: time and money are tight and the goal is to solve a technical problem with software (e.g. solving social problems with software is a completely different challenge).

Furthermore, we work in a field of tension between stakeholders, employees, customers and not to forget our ethical and moral principles. In most cases, we have to weigh up what is the best decision, when, why and how, and how this can be justified or revised in the future.

So, what is the greatest skill of an experienced developer? I would say that the question already contains the answer, namely it is the experience that distinguishes him from others.

With experience comes foresight, with foresight the resistance to errors increases, and at the same time a more stable system comes to light. With good software, another piece of security and reliability comes into our world. And that, in my opinion, is what is desirable with many technical products.

(translated by deepl.com)

German:
Meistens bist du als Programmierer in einer beschissenen Situation: Zeit und Geld sind knapp und das Ziel ist es, ein technisches Problem mit Software zu lösen (das Lösen von z.B. sozialen Problemen mit Software ist eine ganz andere Herausforderung).

Darüber hinaus arbeiten wir in einem Spannungsfeld zwischen Stakeholdern, Mitarbeitern, Kunden und nicht zu vergessen unseren ethischen und moralischen Grundsätzen. Wir müssen meist situationsspezifisch abwägen, was wann warum und wie die beste Entscheidung ist und wie diese auch in Zukunft gerechtfertigt oder notfalls auch revidiert werden kann.

Also, worin liegt die größte Fähigkeit eines erfahrenen Entwicklers? Ich würde sagen, die Frage bereits die Antwort beinhaltet, nämlich ist es die Erfahrung, die ihn von anderen unterscheidet.

Mit Erfahrun kommt Voraussicht, mit Voraussicht steigt die Fehlerresistenz, womit gleichzeitig ein stabileres System zu Tage kommt. Mit guter Software kommt ein weiteres Stück Sicherheit und Verlass in unsere Welt. Und das ist, was meines Erachtens bei vielen technischen Produkten zu wünschen lässt.

Adding on to everyone's diverse answers & from my know-how / experience,

  1. If you're a 1st generation professional, it's easier to help someone out who comes after you in the same sector.

  2. The realization that willingness to learn from your mistakes (no matter the stage of your career) will take you miles ahead than just being smug about it (especially if you've been in the industry for a long period)

  3. As a DevOps Engineer, the understanding of which commands are not to be run given any situation.

  4. Technology comes back in circles.

One thing I have seen is that they lack understanding of how to test things. It's not their fault. Most schools and universities that teach Computer Science often dont focus on this and might have a class on it, but that's it. I find that troubling. When ever we have an intern I take the time to teach them the TDD and how to write good unit tests.

Creating code/architecture/software that doesn't readily come back to haunt you or bite you in the proverbial backside. Or to put in another way: it takes quite some time and effort to (learn to) write software in a way that requires less time and effort.

Two points that come to my mind:

1) Shell one-liners that will immediately do exactly what you want.
From my own experience - tasks that would take me 10 minutes of using mice and file explorer now take only seconds once I became fluent in using basic shell commands and pipe them together. Before becoming professional I naturally didn't have to repeat same and same operation every day just to check something.

2) Use of Automation tools - especially in in webdev. When I was learning stuff myself - pressing F5 to refresh page was basically done hundreds of times. Now I cannot imagine life without browserSync, gulp/bower or puryfiCSS

I assume (as a completely backend developer) the most crucial skill is various business logic knowledge.
I would also mention the ability to ask "why should I..." and answer "no".

  • It’s ok to abstract stuff (you don’t get)
  • it works in a team’s favour to ask for second opinion(/s)
  • you must carry on being curious

DRY and CI into mind.

Don’t repeat yourself and continuously integrate (new stuff) into (anybodys) mind 🤓

Avoiding work while appearing busy? 😇

Handling this situation in a cool and convenient way. Learning things and beeing curious makes so much fun. It’s hard to convince people that it makes so much fun, they won’t believe ya.

As I grow as a developer, I realise it is totally OK to not know certain skills and technologies.

Logical thinking and Problem solving techniques is what matters.

  • Troubleshooting.
  • Understanding every single program only does 3 things.
  • Working as a team.
  • Software Version Control.

What are these three things? Let me try, saving, mutating, deleting?

The main two I've discovered involve knowing when to take a break and of course when to go back to the drawing board. 🎉👨‍💻

Communication, it can be with your colleges or with people that have zero knowledge about programming and computers

Selecting the right tool for the job

I’d say that something I have learnt through experience is to not to overengineer the solutions I propose and estimate better how long does it take to do something.

I believe farsightedness can only come from experience and its very valuable for more complex solutions and the future of them.

Can be similar as mature people does in real life.

What about security?

This is a skill I feel has to be part of every curriculum but is often overlooked.

Do you think secure coding comes with experience, or is a fundamental aspect of development?

Debugging - You have to experience bugs/glitches/failures before you know how to fix them.

Classic DEV Post from Apr 30

What is your favourite git merge tool/strategy?

VSCode is my favourite editor. But while rebasing and resolving merge conflicts...

Ben Halpern
A Canadian software developer who thinks he’s funny.
Join dev.to

Top devs blog here. Free forever.