9 ms·

This makes me miss my early days of programming, where no code was too verbose or horrible to stop me from progressing towards my goal, no matter how misguided

This makes me miss my early days of programming, where no code was too verbose or horrible to stop me from progressing towards my goal, no matter how misguided I was. Nowadays I'm distracted by the first hint that there might be some better way, and all progress stops. I think I'm just beginning to recognize this, and maybe one of these years I'll learn to recognize when the right abstraction is really important and when it's not worth sweating the small stuff.

jackmott 9y ago
watching the creator of The Witness do some live stream coding made me realize this too. he just typed the convenient thing he needed at each moment and didn't try to abstract away the mess. just forged ahead.
- baby 9y ago
  Thinking of video game, I think this is a good analogy: a lot of what you write in the beginning are just tools to your own program. I'm really talking about the lines in your code, they're structured so well that they will help forge more code in the middle and later parts of your code life. Like any good video game, if you produce good tools in the beginning to produce levels, modes, multi-player games, etc... then you will produce something great. If you don't care about what you're writing, then it will become a huge mess and you will either give up or your users will give up. Or once in a life time, the mess you created will still be fun enough that everyone will start playing it, deadmau5 will make a tattoo of it and Microsoft will buy you out and you will have the most expensive house in the world/LA.
  - jackmott 9y ago
    But you can go too far there. The Witness guy explained it like this: You need to do a breadth first search of your code. If you rabbit hole for weeks making the perfect level design tool before you have already made a working prototype of the game for example, you might then months later, as you build out the game, realize the level building tool you have made isn't really suitable. As you start filling out the breadth of your design a time will come when you know an idea is going to work, and you have more knowledge to inform your tool. Of course to what extent you should approach the coding breadth first vs depth first will depend on how clear of an idea you have for the design. If you were just doing a near-clone of Doom and you have done this before then maybe you can just rabbit hole pretty deep from the get go.
- DanielRibeiro 9y ago
  Oh yeah, Jonathan Blow's coding videos show an amazing exercise of pragmatism: https://www.youtube.com/user/jblow888/videos https://www.youtube.com/user/jblow888/videos
seanmcdirmid 9y ago
It is often impossible to write code the first time anyways, just do it, realize your technical debt, and come back and refactor it when the better abstraction is more obvious (if any).
- stevenwoo 9y ago
  Ah, but try that in an interview and see what happens.
  - seanmcdirmid 9y ago
    Interview coding skills are different from real world coding skills.
    - stevenwoo 9y ago
      Yes, sorry I was not clear. The OP was correct in stating that sometimes one just need to get started, but it's hilarious that what one does in the real world is not something that is valued in an interview where one is expected to come up with a solution and iterate on it to have it fully optimized in 45 minutes.
  - cabaalis 9y ago
    I'm no Google, but I would hire someone who follows that methodology. 1. Make it work 2. Make it work fast 3. Make it work well In that order.
- imron 9y ago
  Compression oriented programming - https://mollyrocket.com/casey/stream_0019.html https://mollyrocket.com/casey/stream_0019.html
  - seanmcdirmid 9y ago
    Sounds like gradual abstraction.
0xbear 9y ago
By the time this happens you’ll be “overqualified” and “unlikely to be happy”, and therefore unemployable.
awj 9y ago
Premature abstraction is generally worse than immature abstraction. Write the most straightforward thing you can, and wait for that feeling that it won't work out. Then, ignore that feeling until you get proof. If you've kept your code simple and clean reacting to a lack of abstraction is relatively easy, at least compared to what digging yourself out of the wrong abstraction is like.
- dkural 9y ago
  YES, this 100 times.
- adrianratnapala 9y ago
  Indeed, it is concreteness that is the virtue and abstraction that is the necessary evil. We sometimes lose sight of this because when we learn that abstraction is necessary, and see how beautiful it can be, we forget that it is an extra layer of mental indirection.
- always_good 9y ago
  Sandi Metz's piece on this: https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...
- misja111 9y ago
  This is so true. Even a horrible God class with 6500 lines of code is still many times better than an overdesigned framework with 100 classes of 65 lines each.
  - siliconunit 9y ago
    Totally agree, and as for ownership imho it all depends what level of complexity we are a taking about, if it's some web bs (no offense) it's one thing, if we talking about some parallel gpu FEM physics solver trust me there will be ownership and I think it's a good thing...
  - posterboy 9y ago
    hard to tell what you think would be the significant difference between horrible and overdesigned.
Iv 9y ago
As I had to work more with teams and then supervising teams I changed the abstractions I value from when I was programming solo: Now I care less about my project's function than the structure of the team. There is a saying that any complex project will end up mimicking the communication structure of your organization. I must confess I thought it was silly until I realized it happened to us. I now favor code that has a lot of independent modules that can have hacky inner code but that must have clear, explicit and preferably simple interfaces. The project's manager role is to design these interfaces and has the last work on their implementation. This is a bit the Unix way. Every module has to do one thing (and optionally do it well). This allows veteran programmers who know all the subtleties of the programming language to collaborate with rookie programmers who may write okay-ish modules that we may have to rewrite later but that work well enough. It also allows programmers, these very territorial beasts, to have their own little realms they control and where they are acknowledged. It helps non-tech managers understand who has to be assigned on different issues and evolutions.
- Clubber 9y ago
  Absolutely this. Some people think silos are bad, but it absolutely works brilliantly in terms of team cohesion. No stepping on toes. Few arguments because everyone is responsible for their own stuff. No nitpicking over irrelevant style preferences. Pride in ownership, self accountability, thoughtful decision making (mostly). All this leads to good working relationships that come in handy when cross-realm issues arise. Every place that had a great team did it this way.
  - curun1r 9y ago
    Until someone goes on vacation, their area blows up and everyone else has to panic fix some code that they've never seen before. As a manager, one of my main jobs is ensuring that the team's bus number is always above 1 and scheduling vacation time so that we always have full coverage should stuff go down. There's a huge difference between a silo and giving someone responsibility for driving the design of a component/module. The latter is great, the former is a failure of the team's leadership. You can still get pride of having built something even if you're building it for the team and, through code review, the team is accepting ownership. But individual ownership of key pieces of code has been responsible for most of the top-10 shit storms I've seen in my career and I'm never letting it happen on a team I manage ever again.
wmccullough 9y ago
I miss the rush
staunch 9y ago
"first you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer" https://mobile.twitter.com/KentBeck/status/258316233068396544 https://mobile.twitter.com/KentBeck/status/25831623306839654...
- justicezyx 9y ago
  "Any problem in computer science can be solved with another layer of indirection"
  - Anchor 9y ago
    Except for the problem of too many layers of indirection.
    - adwn 9y ago
      And for the problem of insufficient performance.
      - Rexxar 9y ago
        Cache are a level of indirection and they increase performance.
        adwn 9y ago
        Some problems of insufficient performance can be solved by layers of indirection, but not all. The original quote quantifies over all problems: > "Any problem in computer science can be solved with another layer of indirection" Otherwise, good point – I did not think of this.
CodeWriter23 9y ago
Something I recently read helped me with this. The guy said “refactor often”. So I code the solution for the problem at hand and when something else touches it, and a refactor is necessary, I do it right then, schedule implications be damned. Early on it can be a hellish bit of regressions, but after a time, the refactors move from less disruptive to smooth. And I get two bonuses: technical debt stays low, and analysis paralysis is optional. There’s a trade-off between time to completion and designing debt-free code, and I think that one small mantra helped me find the right balance. And let’s be realistic, the only debt-free code is code that is never touched by new implementation.
voltagex_ 9y ago
Give yourself permission. I have a GitHub repo called "junkcode" for this very purpose - sometimes projects are promoted out of there, sometimes not.
- christophilus 9y ago
  I like that idea a whole lot. I tend to just throw stuff on GitHub. Some is prototypal. Some is polished. Some is just terrible in every way. Your approach seems better, and is aptly named.
  - voltagex_ 9y ago
    I can't take credit for it - the idea came from Andrew Tridgell - https://github.com/tridge/junkcode https://github.com/tridge/junkcode http://samba.org/ftp/tridge/talks/junkcode.pdf%E2%80%8E http://samba.org/ftp/tridge/talks/junkcode.pdf%E2%80%8E
- themoat 9y ago
  That's a pretty good idea, actually. Sometimes I throw a repo up to play, but take it down out of insecurity...
zem 9y ago
i keep posting this to hn, but it keeps being relevant: http://prog21.dadgum.com/21.html http://prog21.dadgum.com/21.html
b0rsuk 9y ago
John Carmack's advice (I don't remember exactly): "If you don't know which way is better, do it both ways and compare."
- mikenew 9y ago
  What if you're not sure which of 17 different ways is better?
  - TeMPOraL 9y ago
    Spend a few minutes thinking about the problem in order to reduce those 17 ways into ~3-5 ways, and then apply Carmack's advice.
cel1ne 9y ago
There's a way around that: First time, you do it "like a sketch", no criticism allowed. Then you can work over it. Every creative work that ever got finished was made like that ;). Better finish 80%, than miss 100%.
coltonv 9y ago
Earlier today I wrote a ruby script to go through a JavaScript file, find all ocurrences where a method was written in a certain way, and convert it to a new format. I realized before writing it that there I would never use this script after today, no one ever had to see it, and it would never get version controlled. So i just wrote it in the quickest "get it functional for 95% of cases and throw an error otherwise" It was kind of fun. Multiple parts had godawful big-O run times, multiple anti patterns, etc. But none of that mattered since it would never be used on a massive file and would never be in production. It took me back to that phase where i was young and doing pet projects and i could be as selfish as possible.
- makapuf 9y ago
  That's basically why I have a personal project. Low level C code, no operating system, no heap memory handling on embedded, no problem ! Also, almost no abstractions but "infinite" time spend on pointless micro optimizations tweaking assembly. That's a relief from daily work where I'm much more disciplined.
- louithethrid 9y ago
  .. the next day, my boss called- and he had the exact same problem, so i used the script, so its a tool at our company now, and several collagues added to it.
Gonzih 9y ago
> no code was too verbose or horrible to stop me from progressing towards my goal Sounds like programming in go :) PS. It's a joke, I enjoy go myself.

jackmott 9y ago

watching the creator of The Witness do some live stream coding made me realize this too. he just typed the convenient thing he needed at each moment and didn't try to abstract away the mess. just forged ahead.

baby 9y ago
Thinking of video game, I think this is a good analogy: a lot of what you write in the beginning are just tools to your own program. I'm really talking about the lines in your code, they're structured so well that they will help forge more code in the middle and later parts of your code life. Like any good video game, if you produce good tools in the beginning to produce levels, modes, multi-player games, etc... then you will produce something great. If you don't care about what you're writing, then it will become a huge mess and you will either give up or your users will give up. Or once in a life time, the mess you created will still be fun enough that everyone will start playing it, deadmau5 will make a tattoo of it and Microsoft will buy you out and you will have the most expensive house in the world/LA.
- jackmott 9y ago
  But you can go too far there. The Witness guy explained it like this: You need to do a breadth first search of your code. If you rabbit hole for weeks making the perfect level design tool before you have already made a working prototype of the game for example, you might then months later, as you build out the game, realize the level building tool you have made isn't really suitable. As you start filling out the breadth of your design a time will come when you know an idea is going to work, and you have more knowledge to inform your tool. Of course to what extent you should approach the coding breadth first vs depth first will depend on how clear of an idea you have for the design. If you were just doing a near-clone of Doom and you have done this before then maybe you can just rabbit hole pretty deep from the get go.
DanielRibeiro 9y ago
Oh yeah, Jonathan Blow's coding videos show an amazing exercise of pragmatism: https://www.youtube.com/user/jblow888/videos https://www.youtube.com/user/jblow888/videos

seanmcdirmid 9y ago

It is often impossible to write code the first time anyways, just do it, realize your technical debt, and come back and refactor it when the better abstraction is more obvious (if any).

stevenwoo 9y ago
Ah, but try that in an interview and see what happens.
- seanmcdirmid 9y ago
  Interview coding skills are different from real world coding skills.
  - stevenwoo 9y ago
    Yes, sorry I was not clear. The OP was correct in stating that sometimes one just need to get started, but it's hilarious that what one does in the real world is not something that is valued in an interview where one is expected to come up with a solution and iterate on it to have it fully optimized in 45 minutes.
- cabaalis 9y ago
  I'm no Google, but I would hire someone who follows that methodology. 1. Make it work 2. Make it work fast 3. Make it work well In that order.
imron 9y ago
Compression oriented programming - https://mollyrocket.com/casey/stream_0019.html https://mollyrocket.com/casey/stream_0019.html
- seanmcdirmid 9y ago
  Sounds like gradual abstraction.

0xbear 9y ago

By the time this happens you’ll be “overqualified” and “unlikely to be happy”, and therefore unemployable.

awj 9y ago

Premature abstraction is generally worse than immature abstraction. Write the most straightforward thing you can, and wait for that feeling that it won't work out. Then, ignore that feeling until you get proof. If you've kept your code simple and clean reacting to a lack of abstraction is relatively easy, at least compared to what digging yourself out of the wrong abstraction is like.

dkural 9y ago
YES, this 100 times.
adrianratnapala 9y ago
Indeed, it is concreteness that is the virtue and abstraction that is the necessary evil. We sometimes lose sight of this because when we learn that abstraction is necessary, and see how beautiful it can be, we forget that it is an extra layer of mental indirection.
always_good 9y ago
Sandi Metz's piece on this: https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...
misja111 9y ago
This is so true. Even a horrible God class with 6500 lines of code is still many times better than an overdesigned framework with 100 classes of 65 lines each.
- siliconunit 9y ago
  Totally agree, and as for ownership imho it all depends what level of complexity we are a taking about, if it's some web bs (no offense) it's one thing, if we talking about some parallel gpu FEM physics solver trust me there will be ownership and I think it's a good thing...
- posterboy 9y ago
  hard to tell what you think would be the significant difference between horrible and overdesigned.

Iv 9y ago

As I had to work more with teams and then supervising teams I changed the abstractions I value from when I was programming solo: Now I care less about my project's function than the structure of the team. There is a saying that any complex project will end up mimicking the communication structure of your organization. I must confess I thought it was silly until I realized it happened to us. I now favor code that has a lot of independent modules that can have hacky inner code but that must have clear, explicit and preferably simple interfaces. The project's manager role is to design these interfaces and has the last work on their implementation. This is a bit the Unix way. Every module has to do one thing (and optionally do it well). This allows veteran programmers who know all the subtleties of the programming language to collaborate with rookie programmers who may write okay-ish modules that we may have to rewrite later but that work well enough. It also allows programmers, these very territorial beasts, to have their own little realms they control and where they are acknowledged. It helps non-tech managers understand who has to be assigned on different issues and evolutions.

Clubber 9y ago
Absolutely this. Some people think silos are bad, but it absolutely works brilliantly in terms of team cohesion. No stepping on toes. Few arguments because everyone is responsible for their own stuff. No nitpicking over irrelevant style preferences. Pride in ownership, self accountability, thoughtful decision making (mostly). All this leads to good working relationships that come in handy when cross-realm issues arise. Every place that had a great team did it this way.
- curun1r 9y ago
  Until someone goes on vacation, their area blows up and everyone else has to panic fix some code that they've never seen before. As a manager, one of my main jobs is ensuring that the team's bus number is always above 1 and scheduling vacation time so that we always have full coverage should stuff go down. There's a huge difference between a silo and giving someone responsibility for driving the design of a component/module. The latter is great, the former is a failure of the team's leadership. You can still get pride of having built something even if you're building it for the team and, through code review, the team is accepting ownership. But individual ownership of key pieces of code has been responsible for most of the top-10 shit storms I've seen in my career and I'm never letting it happen on a team I manage ever again.

wmccullough 9y ago

I miss the rush

staunch 9y ago

"first you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer" https://mobile.twitter.com/KentBeck/status/258316233068396544 https://mobile.twitter.com/KentBeck/status/25831623306839654...

justicezyx 9y ago
"Any problem in computer science can be solved with another layer of indirection"
- Anchor 9y ago
  Except for the problem of too many layers of indirection.
  - adwn 9y ago
    And for the problem of insufficient performance.
    - Rexxar 9y ago
      Cache are a level of indirection and they increase performance.
      - adwn 9y ago
        Some problems of insufficient performance can be solved by layers of indirection, but not all. The original quote quantifies over all problems: > "Any problem in computer science can be solved with another layer of indirection" Otherwise, good point – I did not think of this.

CodeWriter23 9y ago

Something I recently read helped me with this. The guy said “refactor often”. So I code the solution for the problem at hand and when something else touches it, and a refactor is necessary, I do it right then, schedule implications be damned. Early on it can be a hellish bit of regressions, but after a time, the refactors move from less disruptive to smooth. And I get two bonuses: technical debt stays low, and analysis paralysis is optional. There’s a trade-off between time to completion and designing debt-free code, and I think that one small mantra helped me find the right balance. And let’s be realistic, the only debt-free code is code that is never touched by new implementation.

voltagex_ 9y ago

Give yourself permission. I have a GitHub repo called "junkcode" for this very purpose - sometimes projects are promoted out of there, sometimes not.

christophilus 9y ago
I like that idea a whole lot. I tend to just throw stuff on GitHub. Some is prototypal. Some is polished. Some is just terrible in every way. Your approach seems better, and is aptly named.
- voltagex_ 9y ago
  I can't take credit for it - the idea came from Andrew Tridgell - https://github.com/tridge/junkcode https://github.com/tridge/junkcode http://samba.org/ftp/tridge/talks/junkcode.pdf%E2%80%8E http://samba.org/ftp/tridge/talks/junkcode.pdf%E2%80%8E
themoat 9y ago
That's a pretty good idea, actually. Sometimes I throw a repo up to play, but take it down out of insecurity...

zem 9y ago

i keep posting this to hn, but it keeps being relevant: http://prog21.dadgum.com/21.html http://prog21.dadgum.com/21.html

b0rsuk 9y ago

John Carmack's advice (I don't remember exactly): "If you don't know which way is better, do it both ways and compare."

mikenew 9y ago
What if you're not sure which of 17 different ways is better?
- TeMPOraL 9y ago
  Spend a few minutes thinking about the problem in order to reduce those 17 ways into ~3-5 ways, and then apply Carmack's advice.

cel1ne 9y ago

There's a way around that: First time, you do it "like a sketch", no criticism allowed. Then you can work over it. Every creative work that ever got finished was made like that ;). Better finish 80%, than miss 100%.

coltonv 9y ago

Earlier today I wrote a ruby script to go through a JavaScript file, find all ocurrences where a method was written in a certain way, and convert it to a new format. I realized before writing it that there I would never use this script after today, no one ever had to see it, and it would never get version controlled. So i just wrote it in the quickest "get it functional for 95% of cases and throw an error otherwise" It was kind of fun. Multiple parts had godawful big-O run times, multiple anti patterns, etc. But none of that mattered since it would never be used on a massive file and would never be in production. It took me back to that phase where i was young and doing pet projects and i could be as selfish as possible.

makapuf 9y ago
That's basically why I have a personal project. Low level C code, no operating system, no heap memory handling on embedded, no problem ! Also, almost no abstractions but "infinite" time spend on pointless micro optimizations tweaking assembly. That's a relief from daily work where I'm much more disciplined.
louithethrid 9y ago
.. the next day, my boss called- and he had the exact same problem, so i used the script, so its a tool at our company now, and several collagues added to it.

Gonzih 9y ago

> no code was too verbose or horrible to stop me from progressing towards my goal Sounds like programming in go :) PS. It's a joke, I enjoy go myself.