Live data from Hacker News

Choose Boring Technology

boringtechnology.club

71–80 of 356 posts

Re: Choose Boring Technology

#71

Earlier quoted context omitted.

Code is not "a liability". It is a tool that can be used masterfully or utterly abused. Every craftsman has to invest in their tools. And for someone to truly master their craft they must sometimes hone their tool skills speculatively, without short-term gain, and by sacrificing the time and attention used for other things, like actual projects. If everyone just obeyed their project manager and always focused 100% on…

Code absolutely is a liability. It is not a tool, it's a means to an end. A simple tool, like a hammer, is not volatile over time. The house that you build with your tools is. It will weaken and rot, and given enough time it will crumble. It takes care and maintenance to keep it safe to live in. It is the same with code in production; at some point in time in the future, through no fault of your own, the code can bec…

Strictly speaking, code is both an asset and a liability (as in double entry book keeping, you can’t have one without the other). It depreciates over time.

A simple tool like a hammer is rarely treated like an asset as it is expensed up front.

Code can generate cash flow through its replication and exchange, or its application. Whether this is higher than its depreciation and maintenance costs determines whether you’re losing money on it.

The above is an analogy of course, In actual financial accounting we typically see only see code or “knowledge capital” on the books after acquiring another company, usually as a fat chunk of “goodwill”.

Re: Choose Boring Technology

#72
This so depends on the talent of your team. If you are normal then play it safe as most of us are. But if you want to make something great then you must resort to exploration, discovery and invention.

Re: Choose Boring Technology

#73
post #16

There's a longer term issue that appears to be missing here. At what point do you change? There must be a point otherwise we'd all be here writing COBOL/CICS with some whizzy Javascript interface library. Over time it becomes harder and harder and more and more expensive to maintain old technology. Because frankly maintaining old technology is pretty boring and career destroying so you need to be paid more and more t…

You know, it's the same as with financial advice. Good financial advice is good.... except if absolutely everyone applies it, then it becomes a disaster. Fortunately, there's no risk of that happening. Same here. No matter what you do, leave others to try the cool new stuff & get burned by it & work to fix it (when/if possible). Stay informed, but don't be an early-adopter. It's sound advice - though it wouldn't be i…

To quote Terry Prattchet: The second rat gets the cheese.

Re: Choose Boring Technology

#74
post #41

Earlier quoted context omitted.

For me, change happens when I see a real improvement in almost every way possible which is usually determined by building a few things and letting my brain simmer on the technology as a whole so I can look at it with a logical and unbiased perspective. I remember looking at Node when it first came out and got mildly excited, but that excitement quickly went away after writing a couple of small apps with it. It just w…

Go is a compiled language and Ruby/Python are interpreted scripting languages. There are domains where it's a much more appropriate choice (distributing binaries, performance sensitive code). The type system is also quite nice vs. dynamic typing (in most situations). It's weird to see people comparing Go and Python in this thread as they solve entirely different problems and shouldn't be interchangeable, not due to d…

> Ruby/Python are interpreted scripting languages

This is not quite right since they both compile to bytecode and execute in a virtual machine

shell scripting is, probably, the very rare example of "interpreted"

Re: Choose Boring Technology

#75
post #41

Earlier quoted context omitted.

For me, change happens when I see a real improvement in almost every way possible which is usually determined by building a few things and letting my brain simmer on the technology as a whole so I can look at it with a logical and unbiased perspective. I remember looking at Node when it first came out and got mildly excited, but that excitement quickly went away after writing a couple of small apps with it. It just w…

Go is a compiled language and Ruby/Python are interpreted scripting languages. There are domains where it's a much more appropriate choice (distributing binaries, performance sensitive code). The type system is also quite nice vs. dynamic typing (in most situations). It's weird to see people comparing Go and Python in this thread as they solve entirely different problems and shouldn't be interchangeable, not due to d…

They do overlap. I don't see how someone can be confused about this at all because the overlap is obvious.

Python and golang overlap for http webapps or apis. They both can and often are used for this purpose.

Re: Choose Boring Technology

#76
post #62

Earlier quoted context omitted.

Go is a compiled language and Ruby/Python are interpreted scripting languages. There are domains where it's a much more appropriate choice (distributing binaries, performance sensitive code). The type system is also quite nice vs. dynamic typing (in most situations). It's weird to see people comparing Go and Python in this thread as they solve entirely different problems and shouldn't be interchangeable, not due to d…

> fundamental features of the language The thing is you’re right, Go compiling to a self-contained binary is different from a folder of .py scripts. But both can be deployed into production. The deployment steps are different but the outcome is the same, so they can be used interchangeably.

If you use third party Python libraries, the end user is going to have to install them too. Python really isn't a great language to be building consumer distributed command line apps in.

I think a lot of this discussion is focused around custom software or backend software, but for a publicly distributed binary, Go or any other compiled language is much better than Ruby or Python (and especially Javascript).

Re: Choose Boring Technology

#77
post #28

Earlier quoted context omitted.

This works, but it does force you to ignore new enabling technologies that make new use cases economical, where most innovation and value creation is. You'll be very efficient at accomplishing old use cases, which is just as well, because you'll need it - the market for them is most probably commodified, very competitive, and with low margins. Dominated by big actors with economies of scale. Not a comfortable place t…

You're talking about a tech stack, which is not the same as, for example, a modern web application. You can build a perfectly modern web app with 'old' Java/JEE stack, backed by an unsexy SQL-based database. You don't need Node.js with MongoDB. Techstacks very very very rarely enable new use-cases. They are the equivalent of fashion statements by young developers who haven't learned what it means to support software…

Do you similarly feel like frontend stacks have seen no meaningful innovation?

I think your argument works fine-ish for backends but it's bananas to suggest that jQuery is the same thing as React or Svelte. I do security for a living and maybe 100% of all jQuery sites have XSS. If I find a React page I can just grep for dangerouslySetInnerHTML and I'm 80% of the way there. (I am exaggerating, but hopefully my point is clear: from both a development perspective and a safety perspective, React is not just a shiny new version of jQuery.)

Re: Choose Boring Technology

#78
post #54

Earlier quoted context omitted.

Go is a compiled language and Ruby/Python are interpreted scripting languages. There are domains where it's a much more appropriate choice (distributing binaries, performance sensitive code). The type system is also quite nice vs. dynamic typing (in most situations). It's weird to see people comparing Go and Python in this thread as they solve entirely different problems and shouldn't be interchangeable, not due to d…

> It's weird to see people comparing Go and Python in this thread as they solve entirely different problems and shouldn't be interchangeable, not due to developer preference but due to fundamental features of the language. Yes but when Go first came out, a lot of people jumped on the bandwagon and started proposing they would use Go for web applications too. There's definitely some overlap in building web services wi…

> Go and Python are also pretty related for command line apps too. You could totally use either one to build a CLI tool.

Distribution of Go CLI apps is much easier as you don't need to have your end users install the 3rd party libraries themselves.

Re: Choose Boring Technology

#79

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 surprise…

> "Happiness comes from shipping stuff"

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

Re: Choose Boring Technology

#80

Earlier quoted context omitted.

Go is a compiled language and Ruby/Python are interpreted scripting languages. There are domains where it's a much more appropriate choice (distributing binaries, performance sensitive code). The type system is also quite nice vs. dynamic typing (in most situations). It's weird to see people comparing Go and Python in this thread as they solve entirely different problems and shouldn't be interchangeable, not due to d…

They do overlap. I don't see how someone can be confused about this at all because the overlap is obvious. Python and golang overlap for http webapps or apis. They both can and often are used for this purpose.

Go has other problem domains it is appropriate for, but I agree in this domain there is some overlap. Go and Python have very different performance characteristics though, so in that sense they're not really comparable.
Post reply on HN