DEV Community

Ben Halpern
Ben Halpern Subscriber

Posted on

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.

Top comments (87)

Collapse
 
biros profile image
Boris Jamot ✊ /

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.

Collapse
 
motss profile image
Rong Sen Ng

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.

Collapse
 
biros profile image
Boris Jamot ✊ /

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.

Collapse
 
omrisama profile image
Omri Gabay

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

Collapse
 
dangolant profile image
Daniel Golant

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.

Collapse
 
biros profile image
Boris Jamot ✊ /

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

Collapse
 
michael profile image
Michael Lee 🍕

Hey Boris, was curious what PO stands for?

Collapse
 
dhnaranjo profile image
Desmond Naranjo

I'm guessing Product Owner.

Thread Thread
 
biros profile image
Boris Jamot ✊ /

Exactly!

Collapse
 
ben profile image
Ben Halpern

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.

Collapse
 
buphmin profile image
buphmin

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.

Collapse
 
thebazshah profile image
Muhammad Shahbaz • Edited

Productivity also includes the way you are using your machine, development tools, shortcut keys, code snippets, boilerplate code etc. for a particular programming language. These are some of things I look for, after getting good grip on programming language I am working with.

Collapse
 
damnjan profile image
Damnjan Jovanovic

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
Collapse
 
sergio profile image
deleteme deleteme

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

Collapse
 
david_j_eddy profile image
David J Eddy

Is that 30 estimated years? :D

Collapse
 
isaacdlyman profile image
Isaac Lyman

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/

Collapse
 
syzer profile image
syzer

Almost 20 years in business and still cannot estimate.

Collapse
 
swfisher profile image
Sam Fisher

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

Collapse
 
carlymho profile image
Carly Ho 🌈

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.

Collapse
 
prateek_gogia profile image
Prateek Gogia

The estimation is something I think I can never do properly. It's just so difficult. My speed of coding and analysing the whole situation can surely and has improved very much compared to last years but this estimation thing is just too much for my brain to handle.

Collapse
 
nextlevelshit profile image
Michael Werner Czechowski

Surpises sound to much fun 🎉😂

Collapse
 
nextlevelshit profile image
Michael Werner Czechowski

Point two makes me 🤔 thank you!

Collapse
 
isaacdlyman profile image
Isaac Lyman

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

Collapse
 
drylabrebel profile image
Geoff English

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.

Collapse
 
bizzy237 profile image
Yury

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

Collapse
 
tabuz profile image
Trebuh

"Best Practices™" - I love it !

Collapse
 
elmuerte profile image
Michiel Hendriks

How to fail fast and properly.

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

Collapse
 
boceto1 profile image
Jean Karlo Obando Ramos

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

Collapse
 
carlymho profile image
Carly Ho 🌈

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

Collapse
 
elmuerte profile image
Michiel Hendriks

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!

Thread Thread
 
boceto1 profile image
Jean Karlo Obando Ramos

Ooo I understand. Thanks for your advice

Collapse
 
kspeakman profile image
Kasey Speakman

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.

Collapse
 
umardaraz profile image
umar-daraz

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

Collapse
 
aspittel profile image
Ali Spittel

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

Collapse
 
seimic profile image
seimic

Fully agree. Usually an experienced developer imagines the solution while people are talking about the idea. The hard part is to share the thinking with less experienced once. They tend to loose themselves in details and can’t follow your thoughts.

Collapse
 
shaunakpp profile image
Shaunak Pagnis

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.

Collapse
 
ice_lenor profile image
Elena

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