6 ms·

Always glad to see this making the rounds, as it has been influential for me, especially the perspective of "Happiness comes from shipping stuff". I often thin

Always glad to see this making the rounds, as it has been influential for me, especially the perspective of "Happiness comes from shipping stuff". I often think about this part, in particular: >Then we walked away. We didn’t do anything related to activity feeds for years after that. We barely even thought about it. >Then one day I said, “hey, I wonder how activity feeds is doing.” And I looked at it and was surprised to discover that in the time since we’d launched it, the usage had increased by a factor of 20. And as far as I could tell it was totally fine. >The fact that 2,000% more people could be using activity feeds and we didn’t even have any idea that it was happening is certainly the greatest purely technical achievement of my career. I get a huge kick from making something, and then forgetting about it. For me, implementing something that provides value with near-zero maintenance for years is the ultimate sign that I've done well.

stinos 7y ago
For me, implementing something that provides value with near-zero maintenance for years is the ultimate sign that I've done well. Such a good point it's worth repeating. We have a bunch of small tools of which the code might not exactly be brilliant or adhering all possible good practices, but after 10+ years they still just work without any unsurprising behavior nor bugs and still also just build/deploy with a click of the button so to speak. That's just nice. Does make me wonder sometimes what exactly all other knowledge I gathered since then is good for. Some of it is definitely wasted on shiny stuff. But most of it is software architecture and with repect to the subject I'd translate that as 'how do I make this large scale application a combination of all those small and nice tools, and make that combination itself also work as those small nice tools'.
- jasim 7y ago
  I've found that systems usually get robust over time - most issues in commonly run code paths get ironed out in production, and if we don't keep modifying the code, and the system's relative external world remains stable, things chug along. It is the greatest feeling though! We have a DOS application (inventory, accounts etc.) that has been in operation at a couple of retail stores for about 15 years now. No major change after the second year. This transiency of our work as programmers is something I am yet to come to terms with. I can't recollect where, but there was an interesting consolation in that while the code might be transient, the value created was real, and that's what matters. But the code is an artifact of our waking hours; it matters, like memories matter.
  - loulouxiv 7y ago
    You were still deploying a DOS application in 2004 ? Do you mind telling us more about the reasons why ?
    - jasim 7y ago
      That was the only programming environment (CA-Clipper) I knew at the time. VB6 was a thing, but I had some GUI-antipathy, coming from the older, "purer?" world of DOS. Also POS terminals needed first-class keyboard accessibility. SQL wasn't welcome either - you had to give up the fine grained control of row-level cursors in the flat-file xBase database and use a rather unwieldy looking language. I would still love to go back to the ergonomics of building user interfaces in DOS. No mouse, no events, no callbacks - just straight imperative programming where everything, including user input, blocks. Nothing async - even network communication was thru Novell Netware file writes, using shared locks. And a single screen to design: 25 rows and 80 columns, and just 16 colors. After doing GUI work for many years after DOS, thru VB6, jQuery DOM manipulation, Angular etc., ReasonReact and Hooks are the closest I've come to recapturing the ease of building UIs again. I'm also looking forward to trying out concur one of these days (https://github.com/ajnsit/concur-documentation/blob/master/README.md#event-handling https://github.com/ajnsit/concur-documentation/blob/master/R...) -- it is a Haskell GUI library that lets you do evented handling in an imperative-looking manner.
      - pjmlp 7y ago
        Well, if you would be using Turbo Vision, then there was mouse, callbacks, events, the whole stuff. And async would just be a couple of chained interrupts. I also used CA-Clipper, Summer '87 and the OOP variants 5.x. Most of the stuff did use a mouse and some TUI navigation, with menus and stuff, we had a couple of libraries for it. Now doing those forms it was pretty neat.
        jasim 7y ago
        Yeah I used to look longingly at Turbo Vision GUIs, but C++ was scary at the time. Do you think building TUIs with TV was qualitatively better than approaches popular today? Any insights why?
- rb808 7y ago
  > but after 10+ years they still just work I think this is also a mindset of devs who are committed to a job long term. Many places seem to churn through people every few years. If I had to look for a job every year or two I'd be doing resume-trendy "best tool for the job" stuff too. If I knew I'd be on the same system in 2029, I'd be keeping things easy to maintain.
  - ghaff 7y ago
    And in all fairness, many people seem to churn through places every year or two because (among other reasons) they value newness over longer term projects.
    - mcguire 7y ago
      "If you’re giving individual teams (or gods help you, individuals) free reign to make local decisions about infrastructure, you’re hurting yourself globally. It’s freedom, sure. You’re handing developers a ball of chain and padlocks and telling them to feel free to bind themselves to the operational toil that will be with them until the sweet release of grim death." That last sentence really should be, "You’re handing developers a ball of chain and padlocks and telling them to feel free to bind you to the operational toil that will be with you until the sweet release of grim death." They can (and will) pack up their tents and move on well before any consequences appear.
      - nineteen999 7y ago
        Exactly. And then the poor sods who have to come to pick up their (frequently undocumented or poorly documented) train wreck have to try to and keep it running, or rewrite it.
    - potta_coffee 7y ago
      I value stability, but the companies I've worked for haven't provided any. There's definitely two sides to the coin. Would love to find a job that deserves long term commitment.
    - 7y ago
pif 7y ago
> "Happiness comes from shipping stuff" Actually, the rest of your comments points to: "Happiness comes from shipping good stuff"
- wlesieutre 7y ago
  Maybe more that if you ship bad stuff you don't get to keep shipping stuff, you have to stop and worry about keeping the bad stuff running. Be happy by shipping stuff, and keep shipping stuff by shipping good stuff.
- regularfry 7y ago
  "The way to ship good stuff is to ship lots of stuff and keep the good bits" - apologies to Linus Pauling
  - c0vfefe 7y ago
    Or perhaps to build lots of stuff, and only ship the good bits.
    - sgift 7y ago
      If you don't ship it you don't know if it is good or bad.
      - bigiain 7y ago
        You don't know for sure whether it's good. You may know for sure that it's bad.
      - c0vfefe 7y ago
        Shipping it over to user testing will help.
Datenstrom 7y ago
Beautiful code denies its existence so perfectly you forget you wrote it.
- MattPalmer1086 7y ago
  That is a lovely way of putting it. The unfortunate flip side is that everyone else forgets about it too, and one day there's no one left who understands it any more. I came to the conclusion that software which just works invisibly can have a shorter useful life than software that demands some attention every now and again. So don't make your software invisible!
csours 7y ago
Yesterday reviewed my first script that went global about 8 years ago. I think it had one update from my original deployment. =)
- lowercased 7y ago
  In 2017 I got a call from someone saying "the system's down". It was code I'd deployed for them in 2002. Crazy reviewing some of that code. Some was really good, some was... not so much. :)
  - vidanay 7y ago
    My favorite on these old systems...."Your software has a bug" No, at this point there might be some un-anticipated behavior but most likely there is either a piece of hardware going bad or you have changed your procedures and are no longer using the software the same way.
brightball 7y ago
The code that I've shipped that, 10 years later still runs at previous organizations with no support needed is really something I'm very proud of when I look back. At once point we actually wrote an AJAX site that worked in IE6, Firefox and Safari (pre-Chrome), before Prototype, jQuery or JSON was even a thing...and it still worked perfectly 10 years later. All hand coded JS and backend PHP + Java. It's one of the reasons that I get kinda shocked when I see people look at code on Github and then avoid it because it hasn't had a recent commit. It's also of the big reasons that I'm a fan of Elixir, because the language is approaching a point where it's creators consider it "complete". Boring and stable is the goal.
- extra88 7y ago
  > it still worked perfectly 10 years later. All hand coded JS and backend PHP + Java. Is the server running ten-year-old PHP & Java or did you manage to write code not affected by any language changes? I would expect some changes to be necessary for PHP 5.2 era code to keep working even on PHP 5.6.
  - brightball 7y ago
    I know it was still running but I don’t know about the hosting infrastructure upgrades after I left. When it was deployed it was PHP4.
- celticmusic 7y ago
  I built a custom ticketing system for a hosting company, and maintained it over 6 years before ultimately moving on. After the first 6 months in production it basically sat there for 4 years with no bugs, no dropped tickets/emails, and so forth. One of the things I was proudest of is that no one ever EVER went into work hoping the ticketing system would be up. They eventually started asking for changes due to growing as a company, but I love it when my work is so stable people don't even stop to consider that it might not be available that day. During all that time, it was only ever down or malfunctioning when the infrastructure had problems (something I had no control over and a major reason why I eventually moved on).
godshatter 7y ago
I'm always amazed at the lifespan of some of the code I've written over the years. I wrote an api that we use internally in 1996 that is still being used in all of our new production code in that language in our organization. I've learned a lot in the intervening 23 years so looking at some of that code can be a bit jarring. We've had to adapt it a bit when our environment changed a few times, and we've certainly added to it, but I don't think the core code has had any problems that I know of this century. Millennium, I guess, technically. Part of me really wants to rewrite it, but it doesn't make sense from a developer-time perspective (and I don't want to spend the time tracking down the inevitable bugs again).
amelius 7y ago
> Happiness comes from shipping stuff But Buddha says that the road is more important than the destination ...
- rexpop 7y ago
  Does he?
  - grumdan 7y ago
    I know the comment you replied to was in jest, but he did actually say quite the contrary (at least according to Theravada, one major Buddhist tradition): He in several places said the point of all his teachings was to help people put an end to suffering; he only taught the particular things he taught because according to him, they were the best/only way of reaching that goal. Some schools even go so far as to say that the Buddhist path is something to let go of as well at the very end of the process in order to truly reach enlightenment. It's only a tool to get there.
    - HNLurker2 7y ago
      >Some schools even go so far as to say that the Buddhist path is something to let go of as well at the very end of the process in order to truly reach enlightenment. It's only a tool to get there. Interesting view (we share the same). To understand it more simply think as a big ocean. Enlightenment being an island. This is where the 4 stages are named after (stream entrer, non returner etc). Once you reached the island the boat is no longer useful (and the boat being 2500 years old as a tradition is a pretty quality one)
- mcguire 7y ago
  Shipping stuff is the road.
dtjohnnymonkey 7y ago
Systems that provide value over long periods of time with zero input are the opposite of tech debt. Compound interest?

stinos 7y ago

For me, implementing something that provides value with near-zero maintenance for years is the ultimate sign that I've done well. Such a good point it's worth repeating. We have a bunch of small tools of which the code might not exactly be brilliant or adhering all possible good practices, but after 10+ years they still just work without any unsurprising behavior nor bugs and still also just build/deploy with a click of the button so to speak. That's just nice. Does make me wonder sometimes what exactly all other knowledge I gathered since then is good for. Some of it is definitely wasted on shiny stuff. But most of it is software architecture and with repect to the subject I'd translate that as 'how do I make this large scale application a combination of all those small and nice tools, and make that combination itself also work as those small nice tools'.

jasim 7y ago
I've found that systems usually get robust over time - most issues in commonly run code paths get ironed out in production, and if we don't keep modifying the code, and the system's relative external world remains stable, things chug along. It is the greatest feeling though! We have a DOS application (inventory, accounts etc.) that has been in operation at a couple of retail stores for about 15 years now. No major change after the second year. This transiency of our work as programmers is something I am yet to come to terms with. I can't recollect where, but there was an interesting consolation in that while the code might be transient, the value created was real, and that's what matters. But the code is an artifact of our waking hours; it matters, like memories matter.
- loulouxiv 7y ago
  You were still deploying a DOS application in 2004 ? Do you mind telling us more about the reasons why ?
  - jasim 7y ago
    That was the only programming environment (CA-Clipper) I knew at the time. VB6 was a thing, but I had some GUI-antipathy, coming from the older, "purer?" world of DOS. Also POS terminals needed first-class keyboard accessibility. SQL wasn't welcome either - you had to give up the fine grained control of row-level cursors in the flat-file xBase database and use a rather unwieldy looking language. I would still love to go back to the ergonomics of building user interfaces in DOS. No mouse, no events, no callbacks - just straight imperative programming where everything, including user input, blocks. Nothing async - even network communication was thru Novell Netware file writes, using shared locks. And a single screen to design: 25 rows and 80 columns, and just 16 colors. After doing GUI work for many years after DOS, thru VB6, jQuery DOM manipulation, Angular etc., ReasonReact and Hooks are the closest I've come to recapturing the ease of building UIs again. I'm also looking forward to trying out concur one of these days (https://github.com/ajnsit/concur-documentation/blob/master/README.md#event-handling https://github.com/ajnsit/concur-documentation/blob/master/R...) -- it is a Haskell GUI library that lets you do evented handling in an imperative-looking manner.
    - pjmlp 7y ago
      Well, if you would be using Turbo Vision, then there was mouse, callbacks, events, the whole stuff. And async would just be a couple of chained interrupts. I also used CA-Clipper, Summer '87 and the OOP variants 5.x. Most of the stuff did use a mouse and some TUI navigation, with menus and stuff, we had a couple of libraries for it. Now doing those forms it was pretty neat.
      - jasim 7y ago
        Yeah I used to look longingly at Turbo Vision GUIs, but C++ was scary at the time. Do you think building TUIs with TV was qualitatively better than approaches popular today? Any insights why?
rb808 7y ago
> but after 10+ years they still just work I think this is also a mindset of devs who are committed to a job long term. Many places seem to churn through people every few years. If I had to look for a job every year or two I'd be doing resume-trendy "best tool for the job" stuff too. If I knew I'd be on the same system in 2029, I'd be keeping things easy to maintain.
- ghaff 7y ago
  And in all fairness, many people seem to churn through places every year or two because (among other reasons) they value newness over longer term projects.
  - mcguire 7y ago
    "If you’re giving individual teams (or gods help you, individuals) free reign to make local decisions about infrastructure, you’re hurting yourself globally. It’s freedom, sure. You’re handing developers a ball of chain and padlocks and telling them to feel free to bind themselves to the operational toil that will be with them until the sweet release of grim death." That last sentence really should be, "You’re handing developers a ball of chain and padlocks and telling them to feel free to bind you to the operational toil that will be with you until the sweet release of grim death." They can (and will) pack up their tents and move on well before any consequences appear.
    - nineteen999 7y ago
      Exactly. And then the poor sods who have to come to pick up their (frequently undocumented or poorly documented) train wreck have to try to and keep it running, or rewrite it.
  - potta_coffee 7y ago
    I value stability, but the companies I've worked for haven't provided any. There's definitely two sides to the coin. Would love to find a job that deserves long term commitment.
  - 7y ago

pif 7y ago

> "Happiness comes from shipping stuff" Actually, the rest of your comments points to: "Happiness comes from shipping good stuff"

wlesieutre 7y ago
Maybe more that if you ship bad stuff you don't get to keep shipping stuff, you have to stop and worry about keeping the bad stuff running. Be happy by shipping stuff, and keep shipping stuff by shipping good stuff.
regularfry 7y ago
"The way to ship good stuff is to ship lots of stuff and keep the good bits" - apologies to Linus Pauling
- c0vfefe 7y ago
  Or perhaps to build lots of stuff, and only ship the good bits.
  - sgift 7y ago
    If you don't ship it you don't know if it is good or bad.
    - bigiain 7y ago
      You don't know for sure whether it's good. You may know for sure that it's bad.
    - c0vfefe 7y ago
      Shipping it over to user testing will help.

Datenstrom 7y ago

Beautiful code denies its existence so perfectly you forget you wrote it.

MattPalmer1086 7y ago
That is a lovely way of putting it. The unfortunate flip side is that everyone else forgets about it too, and one day there's no one left who understands it any more. I came to the conclusion that software which just works invisibly can have a shorter useful life than software that demands some attention every now and again. So don't make your software invisible!

csours 7y ago

Yesterday reviewed my first script that went global about 8 years ago. I think it had one update from my original deployment. =)

lowercased 7y ago
In 2017 I got a call from someone saying "the system's down". It was code I'd deployed for them in 2002. Crazy reviewing some of that code. Some was really good, some was... not so much. :)
- vidanay 7y ago
  My favorite on these old systems...."Your software has a bug" No, at this point there might be some un-anticipated behavior but most likely there is either a piece of hardware going bad or you have changed your procedures and are no longer using the software the same way.

brightball 7y ago

The code that I've shipped that, 10 years later still runs at previous organizations with no support needed is really something I'm very proud of when I look back. At once point we actually wrote an AJAX site that worked in IE6, Firefox and Safari (pre-Chrome), before Prototype, jQuery or JSON was even a thing...and it still worked perfectly 10 years later. All hand coded JS and backend PHP + Java. It's one of the reasons that I get kinda shocked when I see people look at code on Github and then avoid it because it hasn't had a recent commit. It's also of the big reasons that I'm a fan of Elixir, because the language is approaching a point where it's creators consider it "complete". Boring and stable is the goal.

extra88 7y ago
> it still worked perfectly 10 years later. All hand coded JS and backend PHP + Java. Is the server running ten-year-old PHP & Java or did you manage to write code not affected by any language changes? I would expect some changes to be necessary for PHP 5.2 era code to keep working even on PHP 5.6.
- brightball 7y ago
  I know it was still running but I don’t know about the hosting infrastructure upgrades after I left. When it was deployed it was PHP4.
celticmusic 7y ago
I built a custom ticketing system for a hosting company, and maintained it over 6 years before ultimately moving on. After the first 6 months in production it basically sat there for 4 years with no bugs, no dropped tickets/emails, and so forth. One of the things I was proudest of is that no one ever EVER went into work hoping the ticketing system would be up. They eventually started asking for changes due to growing as a company, but I love it when my work is so stable people don't even stop to consider that it might not be available that day. During all that time, it was only ever down or malfunctioning when the infrastructure had problems (something I had no control over and a major reason why I eventually moved on).

godshatter 7y ago

I'm always amazed at the lifespan of some of the code I've written over the years. I wrote an api that we use internally in 1996 that is still being used in all of our new production code in that language in our organization. I've learned a lot in the intervening 23 years so looking at some of that code can be a bit jarring. We've had to adapt it a bit when our environment changed a few times, and we've certainly added to it, but I don't think the core code has had any problems that I know of this century. Millennium, I guess, technically. Part of me really wants to rewrite it, but it doesn't make sense from a developer-time perspective (and I don't want to spend the time tracking down the inevitable bugs again).

amelius 7y ago

> Happiness comes from shipping stuff But Buddha says that the road is more important than the destination ...

rexpop 7y ago
Does he?
- grumdan 7y ago
  I know the comment you replied to was in jest, but he did actually say quite the contrary (at least according to Theravada, one major Buddhist tradition): He in several places said the point of all his teachings was to help people put an end to suffering; he only taught the particular things he taught because according to him, they were the best/only way of reaching that goal. Some schools even go so far as to say that the Buddhist path is something to let go of as well at the very end of the process in order to truly reach enlightenment. It's only a tool to get there.
  - HNLurker2 7y ago
    >Some schools even go so far as to say that the Buddhist path is something to let go of as well at the very end of the process in order to truly reach enlightenment. It's only a tool to get there. Interesting view (we share the same). To understand it more simply think as a big ocean. Enlightenment being an island. This is where the 4 stages are named after (stream entrer, non returner etc). Once you reached the island the boat is no longer useful (and the boat being 2500 years old as a tradition is a pretty quality one)
mcguire 7y ago
Shipping stuff is the road.

dtjohnnymonkey 7y ago

Systems that provide value over long periods of time with zero input are the opposite of tech debt. Compound interest?