Does experience make you a better programmer? | Hacker News Reader

Does experience make you a better programmer?

austinhenley.com

33 pointsazhenley34 comments

My real world experience tends to be something like the following:

I want to do X, and it's already obvious it's going to be modeled as say a finite state machine in some kind of predetermined hardware. The "computer science" part of the task just doesn't tend to be a very time consuming determination like it is with exam questions designed to probe that specifically.

The first thing that actually saves time for me is how long it takes to grab maximally relevant boilerplate code and make modifications. The second thing is how organized i am about having datasheets, code, etc layed out so i can cross reference things quickly without making mistakes or being distracted.

Things that wasted most of my time are relatively simple issues in hindsight. Now i help younger people hitting those same walls and realize i have in fact gotten faster at those things i used to be doing, but it doesn't matter because my responsibilities have shifted to other areas where i have less experience. I suspect this cycle will never end and that's ok.

I would have thought this to be wholly generalizable.

Experience makes me a better football player if I study and practice with an eye for improvement.

Experience makes me a better weightlifter if I study and practice, if I get the nutrition I need, and so on.

Some of that improvement will come regardless. But most of it, even if not specifically deliberate, requires some element of direction.

Would spending 10,000 hours writing out the Cyrillic alphabet repeatedly enable me to read Russian literature? So then, would spending 10,000 hours writing HTML enable me to write kernel code?

In the end, what is experience but a training of my brain?

Perfect practice makes perfect.

But not regular practice.

-------

Programming is a wide skill. APIs are perhaps more important than language. In most cases, projects evolve and we find out APIs changing underneath us. It's hard to be an expert on any version given how quickly things move today.

But we can have good experience in a wide number of APIs and codebases. If we come across something similar, the experience helps.

What's perfect practice? Deliberate practice?

Do you want to program fast? Then you need to program quickly. Deliberate practice with slowly written / slowly designed code won't make you any faster.

Do you want to program difficult problems? Then you need to solve difficult problems. Writing fast "code jams" won't help you train vs difficult academic, theoretical problems.

Do you want to program Cryptography? Then you need to write correct cryptography code. Practice by writing incorrect / breakable cryptography code (ie: side-channel attacks, timing attacks, etc. etc.) does you no good. You need to actually write the proper cryptocode.

-------

Doing any of these things imperfectly is sadly, less than useful. You end up practicing "bad habits" and making yourself worse as a programmer.

Fortunately, we programmers don't need perfection in most cases. But always remember that while "normal practice" gains a decent level of competence, you don't actually reach the levels of elite skill (in any task, programming included) unless you can execute "perfectly" at least once.

Setting yourself up for perfect execution needs to be a goal in of itself. For students of language, this means practicing the native tongue's accent. For sports, it means practicing the perfect golf swing form, or the perfect strikes in martial arts.

It also means that people of elite skill can "retain" those skills easier than beginners. If you want to practice "10 perfect golf swings", a beginner may have to swing 100 times to do it. But a pro-golfer would execute in just 10 swings (since almost all of their swings are perfect already).

Solving Fizzbuzz and Leetcode questions quickly does not make you a “better programmer”.

Maybe a better programmer but most certainly not a better developer. What i find odd about leetcode is that much of it is highschool olympiad level coding. And with age and experience people forget all that. So in effect, leetcode, albeit wizardry, is a step back. No one has time to solve such nonsense when millions of users need their content served in 40ms across varying devices networks and all while the system communicates with various banks, data stores and servers spread across data centres and timezones. Sure the junior dev can faff with their little function’s code but not a senior dev.

Well indeed, if by ‘developer’ you mean (software) engineer. Engineering is vastly different from the mere coding.

Not in practice. Maybe at university. Software architecture I would agree, software engineers are just developers with formal training. I have not seen any difference in the actual work either does. But even self-taught developers can end uo doing architecture.

end up doing, sure, but I'd argue architectural work is not "mere coding".

It wasn't even solving them! It was reading them.

Not being able to solve them, especially fizzbuzz, does not really help either though

I think if someone is good at such problems then it means they at least know their data structures and have good problem solving skill. Both are good qualities for a programmer.

Sure. But if you can't solve fizzbuzz then the odds of you being a good programmer are very nearly zero. Thus its function as a filter.

I think author's point is someone that has more experience than another, as in he worked more years as a programmer, does not make that person automatically better than the other. I mean, duh. People are different, in my opinion programming is as much as talent as it is experience.

People seems to be confusing it with (rightfully, because that is what title says) "does more experience make you, or anyone else, better than what he used to be". Also obviously correct

Define talent.

Not an exact definition, but it is how fast the experience converts to skill. Imagine two people spending 100 hours doing the same thing, one of them improves more than the other.

I see one of the things missing is the ability to model a problem correctly. Even if you did not learn new algorithms or solve new problems, you learn how to model the problem better. You fix a bug, you learn where the abstraction leaks. You try to build a better model next time.

Experience frees you from the burden of being intimidated by something new. It becomes just get the job done and move on to something else. Dealing with new things become routine if that's not a contradiction in words.

The main benefit I’ve seen with more experience is being able to find better solutions to complex problems more quickly. Essentially, knowing the right way to do things up front rather than figuring it out as you go.

Often there are many design goals (eg low cost, low complexity, time to build, seamless integration with X, performance, memory and/or code footprint (particularly in embedded), compatibility with standard X, extensibility, futureproofing, etc). Tetrising all the pieces is probably NP hard — experience is akin to knowing the solution already, or something similar.

Expeience makes you better at not programming the wrong thing. It's how we old farts keep up with young folks who have more fluid intelligence, time, and energy.

Yes, because of Recognition Primed Decision Making - https://en.wikipedia.org/wiki/Recognition_primed_decision

I don’t know how far the x-axis goes (experience) but I know that debugging improved with practice and diversity of applications developed. Similarly, the ability to pull together the top level design of a new application similarly improved. Language facility improves with practice as in RL with physical languages

Maybe as the end of the article states, toy code is too simple to be a differentiator. But like the 10k hour commentary states, it’s got to be increasingly difficult work, not endless repetitions of three chord pop tunes. Programming is an attempt to render an idea in code. Practice makes perfect.

> comprehend code solutions to Leetcode-like problems

What were you supposed to comprehend? The name of the function was “containsSubstring” and it… checked to see if a string contained a substring. Was there supposed to be a bug in there? If there was, I didn’t see it (although I didn’t spend too terribly long looking for one). The “containsSubstring” variable was unnecessary (it could have just returned true on line 13), but that seems awfully nitpicky.

Maybe author means that it is iterating all the way up to len(input) instead of len(input) - len(word)

Or instead of checking j == len(word)-1 inside the inner loop, you could do that outside, after the loop and return true there

Both are a lot more nitpicky. But author's point is the code is not "wrong" but it is not great either

First thing that came to mind in answering this question relates to project management. Is there a way to teach project decomposition, breaking large amounts of work into logical 2-week sprints? Expertise gives you insights into design, architecture and chunking work. I don't think that it can be taught effectively. You have to learn through experience.

The most important aspect experience gives you is ability to understand the full picture, how what you are doing affects the system as a whole. The second thing experience gives is the ability to jump to solutions (that won't fail in production) quicker when the requirements are incomplete because domain knowledge grows.

Experienced programmers may not need to solve those riddles. Try measuring performance at complex problems they face everyday. I don't mean to know that all seniors perform better at this task. But at least measure something of interest.

Do you feel you are better at your job than 5 years ago? I guess it depends how much effort you put in, but I bet most people are, even if they have forgotten certain techniques they haven’t used in those 5 years

Wow, people who reported doing a lot of code review performed better on a "puzzle" code review task.

As did people who reported being better at (something) than their peers.

The headline and article are not supported by the data at all.

Pattern matching makes you a better programmer if you’re changing code, so experience helps more if you’re an original author imho.

Yes. It makes you better. The data provided shows it doesn’t make you as much better as other things but experience will make you better.

I'd say so, but if you keep doing the same thing then you typically don't improve.

If code you wrote five years ago doesn't embarrass you today, you are Doing It Wrong.

The article is obviously wrong. Experience means exercise and exercise helps you to get better in any human endeavor not just programing.

How well a person learning programing since two weeks does when compared to someone who did it for two years?

Also programming means problem solving. Practical programing is not hard the way leet code problems are, practical programming isn't typically requiring you find a very smart algorithm and a very clever approach. Practical programing is hard because it requires massive knowledge, it requires tying those pieces of knowledge together and it requires a very good low level understanding of how systems work.

Being very good at algorithms and data structures will help sometimes - and I enjoy algorithms and data structures and even some of the abstract leet code problems - but knowing that is far from enough, like knowing a programming language is far from enough.

Algorithms are tools, data structures are tools, programming languages are tools, libraries are tools, frameworks are tools, system design, databases, build tools, Ides, debuggers, profilers, cloud, protocols, hardware architecture are all tools. You have to know how to use them and when and why.

Reply on news.ycombinator.com