Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming: Doing it more vs. doing it better

kevinmartinjose.com

Post reply on HN
Print view View original

21–30 of 223 posts

Re: Programming: Doing it more vs. doing it better

#21

Post by ravenstine »

revskill wrote: post #7

I use one rule: If it's easy to remove, then it's fine. Because only then, i don't fear refactoring later. So i'll get my goal: Easy refactoring for fun and profit. Refactoring is often underrated. Actually i learnt more from refactoring rather than "just make it work perfectly since day 1.

Most people talk about KISS, DRY, and YAGNI, but it's uncommon that I meet anyone who actually values replaceability. I don't even mind some repetition of code so long as groups of code aren't tightly-coupled and parts of an application can be easily replaced with rewritten versions.

I had a boss once who was dumbfounded that I actually wanted to refactor code. I guess a lot of people want to write things "perfect" from the very start, but that perfection seems to be a delusion most of the time. The best way to know perfection is to see it in hindsight.

Re: Programming: Doing it more vs. doing it better

#22

Post by munchbunny »

skybrian wrote: post #3

I suspect there may be better ways to practice, rather than just doing it more? Some people put effort into memorization of commonly used idioms. Here's another dubious analogy: when learning music, you do need to practice, but playing a song all the way through a bunch of times is a rather inefficient way to practice it.

Create your own mental frameworks.

For example (personal mnemonic to cover my own blind spots) when designing my feature, consider:

* Flighting, especially protocol changes, will this change cause clients to be unable to talk to services?

* Risk: if this change breaks its service, what else breaks? What is the recovery path?

* Security: does this unintentionally relax or circumvent existing security boundaries? How much damage can an abuse of any code that writes/modifies do?

This is not a complete list on purpose. I use it to shore up the things I tend to forget to think about.

Re: Programming: Doing it more vs. doing it better

#23

Post by bloomca »

hhs wrote: post #13
segmondy wrote: post #11

Earlier quoted context omitted.

Someone programming for 3 yrs is not a beginner, There are people programming at 3 yrs that are experts and will run circles around you and your 38 years. Some people really have the talent and put in the work to get good. In 2019, the mentorship is available via means of books, blogs, MOOC, youtube videos, conferences. What some folks can achieve in 3 yrs these days is really unbelievable. P/S, I have been hacking a…

Interesting view. I'm learning, with about 8 months worth of knowledge and experience, and this is useful. Did you notice any skills/traits in those people who were "unbelievable" in those 3 years? For instance, did they do "test driven development"? Also, did they keep good log habits?

These people have their experience in one field for all these years, therefore they know a lot about it. They also work with limited number of technologies, which makes them good in them.

So, basically, they are good in certain tasks, so as long as they do these tasks you won't notice their lack of experience in other stuff.

> any skills/traits in those people

There are no patterns, to be honest, otherwise everybody would do it. There are best practices (some of them are debatable, like mentioned TDD) which you can read and try to incorporate, but don't treat them as dogmas.

Solve challenging tasks, reflect on your code, try different stuff, actively talk and discuss solutions with more experienced engineers, and you'll learn (relatively) quickly.

Re: Programming: Doing it more vs. doing it better

#24

Post by fourseventy »

segmondy wrote: post #11
kragen wrote: post #8

Someone who's been programming for three years is still a beginner, even though based on what he wrote here, Kevin is almost certainly a lot better than I was when I'd been programming for only three years. I do find that a lot of programming stuff that used to be hard is easier for me now that I've been progrmaming for 38 years. But that doesn't mean I spend all my time doing things I can do without thinking, and it…

Someone programming for 3 yrs is not a beginner, There are people programming at 3 yrs that are experts and will run circles around you and your 38 years. Some people really have the talent and put in the work to get good. In 2019, the mentorship is available via means of books, blogs, MOOC, youtube videos, conferences. What some folks can achieve in 3 yrs these days is really unbelievable. P/S, I have been hacking a…

Programming is no different than any other discipline. You aren't going to be an expert in anything in only 3 years. Expert physician? Wont even be out of residency yet. Expert car mechanic? No way. Expert troll on hacker news? Maybe.

Re: Programming: Doing it more vs. doing it better

#25

Post by d4mi3n »

ravenstine wrote: post #21
revskill wrote: post #7

I use one rule: If it's easy to remove, then it's fine. Because only then, i don't fear refactoring later. So i'll get my goal: Easy refactoring for fun and profit. Refactoring is often underrated. Actually i learnt more from refactoring rather than "just make it work perfectly since day 1.

Most people talk about KISS, DRY, and YAGNI, but it's uncommon that I meet anyone who actually values replaceability . I don't even mind some repetition of code so long as groups of code aren't tightly-coupled and parts of an application can be easily replaced with rewritten versions. I had a boss once who was dumbfounded that I actually wanted to refactor code. I guess a lot of people want to write things "perfect"…

This line of discussion reminds me of a great quote by Sandi Metz, who's pretty well known in the ruby community for harping on the topic. One thing I saw in a talk of hers that really stuck with me: Repetition is preferable to the wrong abstraction.

The first thing that's drilled into a new programmer is DRY. It's easy to understand and it works reasonably well. The next step up seems to be knowing when _not_ to roll stuff up, and how to tell when you're looking at a distinct piece of logic that needs to be reified into it's own entity or function.

EDIT: The Sandi Metz talk I mentioned: https://www.youtube.com/watch?v=8bZh5LMaSmE

Re: Programming: Doing it more vs. doing it better

#26

Post by flocial »

LarryMade2 wrote: post #14

I think when you are starting some new concept, that you are learning as you go you need to just try to do your best of throwing stuff on the wall to get it to work, refactor a lot and keep grinding away. During this time you are building the "Big picture" of what it is. Once you get a good enough big picture then you probably will start to realize where how to optimize the data and create better methods, but even th…

This was my first thought. I think beginners take better to volume but eventually we all hit a wall that takes more deliberate practice and deep reflection. Even then some concepts will be out of reach or take an exceptional teacher to break down. That doesn't even touch on the limits of individual abilities which we all face at some point.

Re: Programming: Doing it more vs. doing it better

#27

Post by hhs »

bloomca wrote: post #23
hhs wrote: post #13

Earlier quoted context omitted.

Interesting view. I'm learning, with about 8 months worth of knowledge and experience, and this is useful. Did you notice any skills/traits in those people who were "unbelievable" in those 3 years? For instance, did they do "test driven development"? Also, did they keep good log habits?

These people have their experience in one field for all these years, therefore they know a lot about it. They also work with limited number of technologies, which makes them good in them. So, basically, they are good in certain tasks, so as long as they do these tasks you won't notice their lack of experience in other stuff. > any skills/traits in those people There are no patterns, to be honest, otherwise everybody…

Very useful. Good notes on solving, reflecting, and actively talking.

And that point you write: "They also work with limited number of technologies, which makes them good in them. So, basically, they are good in certain tasks". An interesting observation, thank you.

Re: Programming: Doing it more vs. doing it better

#28

Post by cheez »

revskill wrote: post #7

I use one rule: If it's easy to remove, then it's fine. Because only then, i don't fear refactoring later. So i'll get my goal: Easy refactoring for fun and profit. Refactoring is often underrated. Actually i learnt more from refactoring rather than "just make it work perfectly since day 1.

Indeed. I love it when the amount of money I make is tied to the quality of my code somehow. Easy to modify, easy to repurpose, easy to replace. These often make it possible to serve customers better -> more $$$

It's why I can't really take a regular job. There is no relationship between the quality of my work and what I get paid.

Re: Programming: Doing it more vs. doing it better

#29

Post by flukus »

leggomylibro wrote: post #17
seba_dos1 wrote: post #2

> Three years later, I am still very much the apprentice. Well, three years is really not a lot when it comes to developing an intuition. Just enough to grasp some basics. > a writer is someone for whom writing is more difficult than it is for other people Yeah, I seem to recall Douglas Adams saying that the easier it is to read a text, the harder it was to write it. At the beginning of my career I was constantly bei…

It might just be one of those universal truths: you need to understand something very well to explain how it works in simple terms. Or as some smart person once said, "brevity is the soul of wit."

"If I had more time, I would have written a shorter letter" - attributed to just about everyone: https://quoteinvestigator.com/2012/04/28/shorter-letter/

Re: Programming: Doing it more vs. doing it better

#30

Post by zjs »

segmondy wrote: post #11
kragen wrote: post #8

Someone who's been programming for three years is still a beginner, even though based on what he wrote here, Kevin is almost certainly a lot better than I was when I'd been programming for only three years. I do find that a lot of programming stuff that used to be hard is easier for me now that I've been progrmaming for 38 years. But that doesn't mean I spend all my time doing things I can do without thinking, and it…

Someone programming for 3 yrs is not a beginner, There are people programming at 3 yrs that are experts and will run circles around you and your 38 years. Some people really have the talent and put in the work to get good. In 2019, the mentorship is available via means of books, blogs, MOOC, youtube videos, conferences. What some folks can achieve in 3 yrs these days is really unbelievable. P/S, I have been hacking a…

To adopt a standard set of terminology — while fully acknowledging the limitations of the model — consider the Dreyfus model of skill acquisition.

I've met or worked with programmers with 3 years of experience who demonstrated competence, but never proficiency.

Some programmers have a strong natural intuition, and a competent programmer with a strong natural intuition may appear proficient. It's a tricky distinction, but important to recognize (especially for the programmers themselves and anyone mentoring them).

However, I think most people with 3 years of professional experience programming are advanced beginners reaching competence in a few specific areas.

Post reply on HN