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.
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'.
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.
A huge part of our VC bubble in OSS infrastructure (NoSQL, clouds, middleware, automation) is fueled by a generation of technologists not choosing boring technology.
This is a great presentation, and great advice.
What this piece misses are the marketing, hiring practices and incentives in that capital pool that is fueling FOMO (fear of missing out) as the main driver of our technology trends.
Most people orbiting IT wants to be a part of something that changes the world: it’s their ticket to higher paying job elsewhere, bragging rights at a conference, internet fame/notoriety via blog posts, etc. This is how we wind up with Service Mesh proxied MongoDB on Kubernetes as THE ANSWER, and all the ensuing political battles / turf wars to fight boring alternatives as “yesterday’s news”.
It would be nice to see a greater focus on business outcomes, but I find few have the patience or bandwidth to truly track the success of a technology choice, unless you’re a larger company making a periodic cash bet with a business partner (eg software vendor). And even then, failure can be swept under the rug sometimes.
It requires strong leadership and management (or a great culture) to encourage your teams to communicate tradeoffs and make these sorts of “boring tech” decisions without it being more about individuals playing a turf game.
There’s a certain amount of ladder kicking involved in telling people to choose boring and beige technologies after you started up your career chasing after new and exciting shiny things.
Every developer should spend some time working at the bleeding edge, so they know how it feels to get cut. The best time is absolutely at the beginning, when you’re a fresh grad and have the energy. You have the rest of your life to work on boring stuff that pays the bills, and who knows, if you are successful with a new technology early on, you might just be working on it for a very long time, continually breaking new grounds.
The problem is that those people who chose shiny new technology only see the benefit, while all the others in the company will rot in hell because of the stupid choice of a junior engineer (who jumped ships 3 times meanwhile). I don't see how does that benefit the company? The whole point of the article is that you should make wise technology decisions which benefits the whole organization.
Surely what you state here can be said of any advice given due to experience. As long as the natural inclinations of younger developers push up against said advice, it's completely sane to give it. Because without it, young developers will have an incomplete mental model, and will lack the intellectual tools to potentially make better choices early in their career.
Also it seems to miss the point somewhat: choosing 'boring' technology has little to do with working on things that are unfulfilling. On the contrary, when tech stack choices are the thing from which developers derive their excitement from, in my view, it's often "empty calories" masking the lack of "emotional nutrition" they are getting from the problem they are solving or the users they are serving. For every whiz-bang neural network getting users to click on ads, there's a 'boring' embedded system running on an ancient C framework somewhere putting satellites in space. I'd rather work on the latter any day of the week.
As Hamming said, "if you're not working on the most important problem in your field, why not?"
Isn't it a bit silly to presuppose that what we have now is the best we are ever going to get. I mean, files were state of the art at one point, but i don't think anyone will suggest we go back to punchcards.
"Boring Technology" is the wrong thing to aim for. Aim for simplicity.
So much this! I mean the author also worked for 7 years at Etsy which did ship quite a lot of new things (bad and good).
For me this is similar to telling a 20 year old, dont go out, stay home, watch tv you will less likely get injured.
The problem is that a lot of shiny new technology is not cutting edge, nor bold. It's just new, and often done more poorly than boring old technology. Also, for someone fresh out of school, you should understand what the status quo is capable otherwise you can't possibly understand what a new technology is really offering.
There's a difference between bold technology and new technology.
A lot of new tech is shiny and provides legitimately useful benefits. Think the new wave of frameworks that started with Rails and Django.
There's a lot of shiny tech that has been a gigantic waste of everyone's time, like MongoDB and people trying to shoehorn MapReduce into every possible computation.
I feel like that's terrible advice for a fresh grad. If they keep getting cut early on, they will lose confidence and start doubting every decision they make, losing motivation to work on anything and burn out.
The interesting thing here is that I find many young engineers want to work on the newest tech, however, they also want the 10-5 schedule.
If you want to work on new and exciting, you have to be willing to own the consequences and stay up late digging into the bugs, learning the ins and outs, and committing to delivering what you said would be delivered. </endrant>
TLDR: If you want to work on interesting, it'll take more commitment.
Another case of someone discovering, after 10+ years in tech, that code is a liability and you're supposed to solve problems instead of chasing trends and padding the resume.
No, your mandate is to advance your career, not solve problems. If you’re rewarded for resume padding more than problem solving then keep resume padding.
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 the problem at hand, we would be producing sad, boring things. If you want to see what that's like look at enterprise applications.
I think the best example of this is IDE and text editor preferences.
They are totally regional, programming-language subculture, and age related
The proponents of Atom/VSCode/Sublime/VIM etc will swear by it to the level of gatekeeping other competent software engineers away from them if they don't use that particular editor, and they all do - or can do - the same thing.
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 to do it.
The marginal benefit of the new shiny is indeed an overhead you should try and avoid, but also you have to dodge the trap of being stuck in a technology when everybody else has moved on.
Author mentions Clojure a few times as an example of shiny-thing. Ironically, it's one of the few languages that I can reliably do in the browser, on the backend (on real servers or say, Lambdas), and build native binaries for -- which addresses the later "many tools" problem better than a "boring" programming language like Ruby. Unless you don't care about frontend code I guess :-)
(Overall this talk is fine! I think the problem/technology set illustration is particularly useful. I run Latacora's Cloud practice and we own all production infrastructure and "no, more boring, boringer than that, keep going" is a good way to describe what that looks like. We deploy half a dozen projects with exactly the same zero config storage and in ECS Fargate because I'm not managing servers.)
But:
- good luck finding a Clojure programmer if your current one quits.
- good luck finding answers for your exotic bug/performance issue
etc.
Code is a liability, it's much more than language/VM/compiler features
Generally, "shiny-things" have some sort of appeal over the "boring" technology, or nobody would choose them at all.
One of the places I'd say they are appropriate are in places where you have some problem where some "shiny-thing" stands head and shoulders above the "boring technology" in some particular and you can ram home those advantages well enough to overcome the other issues. For instance, if you've got a server where you're going to have several thousand clients opening a socket connection and babbling away at each other in some custom manner, starting with Erlang/Elixir is quite possibly a very good idea, because none of the "boring" tech is anywhere near as good at that, even today.
But I do agree that when doing the cost/benefit analyses of these choices, far too many developers plop an unprofessional amount of weight on the "benefit" side that amounts to "it's fun to play with the pretty-shiny". (I'm still recovering from some old "NoSQL" decisions made in a context where a relational database would have been more than adequate, at most backed by something that even at the time was tested like memcached, instead of a combination of what are now completely defunct and semi-defunct databases.)
I'm only part way through the presentation, but I loved this line.
"And when people succumb to this instinct they tell themselves that they’re giving developers freedom. And sure, it is freedom, but it's a very narrow definition of what freedom is."
Yup. You get the freedom to choose a language and/or database with unknowns but you lose the freedom to leave work at a reasonable hour to see your family, pursue a hobby, or just veg out. Experimenting with new (to your organization) languages and infrastructure pieces is something you do between projects, not during.
It reminds me of something a jazz musician said in an interview, "The audience doesn't pay to see you rehearse. Rehearsal is done on your own time away from audiences." Rehearsals are where you try new techniques, harmonies, instruments, etc.
I'm uncomfortable with this rehearsal analogy. I'd rather have a company pay me to learn new things than spend my free time coding when I could be seeing my family, pursuing a hobby, or vegging out. From my employer's perspective, I agree that boring is usually better, but as an individual, I'd rather learn on the job than having to feel the need to "rehearse" for my job.
If you work on a Node backend with Javascript, Where does the idea of switching to Typescript fall into this discussion? Is it a boring technology, or a shiny new technology? It is still using the same tech in Node, which you already know the benefits and pitfalls for, but it isn't like there is no overhead to start consuming Typescript if you haven't used it before.
My hope is for those who agree with the author's premise, that it is still using the same "boring" technology and more people switch to it, because over the last two years when we switched to use Typescript, it has gotten significantly more valuable as more and more people have used it because now a majority of the dependencies I take on have type definitions provided via DefinitelyTyped, or are included with the package.
Like many developers I have a strong desire to work with more exciting technology, even when there's no business case for it. Strangely enough, I've found the best outlet for that energy (other than personal projects when I get free time) is configuring Emacs.
It's less disruptive than putting a new language or database into production, and makes me significantly more content to work with a boring stack. Plus I get a more comfortable computing environment out of it.
Maybe someday I'll get Emacs just the way I like it, and need to find something else to distract me from chasing the new and shiny, but I kind of doubt it.
> "You can’t do poetry if you’re worried about what you’re going to eat today"
Well let me just add this:
> "Shortly after his release from the prison at Meung-sur-Loire he was arrested, in 1462, for robbery and detained at the Châtelet in Paris. He was freed on November 7 but was in prison the following year for his part in a brawl in the rue de la Parcheminerie. This time he was condemned to be pendu et etranglé (“hanged and strangled”). While under the sentence of death he wrote his superb “Ballade des pendus,” or “L’Épitaphe Villon”, in which he imagines himself hanging on the scaffold, his body rotting, and he makes a plea to God against the “justice” of men." - I wouldn't call that the highest step on the pyramid
Somewhat playing devil's advocate, but if everyone joins that club, we keep the status quo and there's no more progress.
If everyone joined this club in the 50's/60's we'd still be writing assembly.
It's the guys pushing new shiny things that allows our domain to go forward, we just need to accept that 90% of the shiny new things eventually turn out to be crap. It's about the other 10%.
You can argue there has been a lot of progress in web development since 2000, and you can argue it hasn't. I think we did a lot of circles around ourselves, creating new frameworks that do the same stuff as the ones before them. The real progress was in browsers and CSS which allowed things like access to device cameras/inputs, rtc technologies and adaptible layouts.
At the end of his shpeel he talks about how to adopt new technologies intelligently. He's not saying that no one ever should but that you need to go about it a certain way to reduce risk.
We are all writing assembly. There are just increasingly powerful levers between us and the assembly. That's why sticking with a technology for so long is powerful - the advances in tooling keep compounding. Imagine if we switched to a completely different paradigm every few years and had to start compiler research over from scratch.
I am in complete agreement with this. (Sing it, brother!)
But,
"My friend Andrew wears the same brand of black shirt every day. He thinks that if he conserves the brainpower it would take to pick something to wear, he’ll bank it and be able to use it later for something else. [...] I like to think about it like this. Let’s say that we all get a limited number of innovation tokens to spend. [...] These represent our limited capacity to do something creative, or weird, or hard. We really don’t have that many of these to allocate. Early on in a company’s life, we get like maybe three. Not too many more than that."
I don't buy this. If you try to save up your brainpower, innovation tokens, intellectual capital, or whatever, what you'll find when you come to try to use it is that you don't have it. Sort of like if you try to save up your upper body strength for a couple of years before you try to climb El Capitan. But I am just saying that is a poor example.
The meme that you can 'save up' or 'train' your mental reserves has seen a bit of a come-back lately. However, the scientific evidence of such a thing is scant to none. In general, people that claim you can train your focus and eureka-moments are not looking at the evidence. Brett at AoM has a good intro article on it here: https://www.artofmanliness.com/articles/motivation-over-disc...
Tl;DR: Be disciplined, not motivated. Don't worry too much as well.
I am more and more resonating with these feelings, for the good and bad. In fact, my own writing reflects that over the years: https://joaodlf.com/ , I started my blog with information regarding technologies like Spark, Cassandra, Go, etc, and I am now writing about Postgres and Python web dev and Celery.
Boring is boring but it simplifies so much. I still love new technology, but I am now much more likely to try it out extensively and privately before even dreaming of bringing it to my company. An example: A few years ago I got very excited about Go, I started introducing it at work and solved some difficult issues with it. I could not get the rest of the developers to gain an interest in the language, though. Effectively, no one else but me could touch any of that code, this is not good for business. I have now revamped that same code, using old technology, and learned a lot along the way - so much so that I now feel like this old tech behaves as nicely as the more complicated, flashy, new language implementation.
I literally had this conversation yesterday as a "why I'm not sure web development is for me, long-term."
The level of familiarity that can be achieved with a tool in the timeframe allotted before the "oh no, we're behind-the-times!" fervor strikes just doesn't seem sufficient to me. I'll have co-workers coming to me with the tool-specific roadblocks they're hitting, and have reached the point where I can easily say "yeah, I've been there, you'd never guess but the problem is with [X], just do [Y]." And just as I'm getting really efficient, I've got to throw it all out because that tool isn't cool anymore, and nobody wants to work with not-cool tools, and we've all got our resumes to worry about.
I wonder if there are some cultural changes that could help mitigate this. If there really is an endorphin rush when working with a fancy new tool, why is that there and what can we do to replace that? Is it resume-building, is it enjoyment of that stage of knowing-nothing, is it happiness when you easily do that one thing that was annoying the shit out of you with the old tool?
Can you pick apart why you were excited about and wanted to adopt Go?
I choose boring technology because it less likely to waste my time. If I choose exciting technology, I will inevitably run into a cryptic error, even if I follow "Getting Started" perfectly, and it will be either difficult or impractical to resolve properly. That happens to me all the time, and I imagine it's due to insufficient testing and developers relying too heavily on their local environment.
Better to work on something boring, but was carefully constructed over time and doesn't require 1/10 the dependencies of today's newfangled thing.
I proudly used "boring" to describe a massive simplification of my work's architecture that I have been working on for the last few years. It has been a successful culling of tech down to the bare minimum (as always- still a work in progress).
Anyway my boss got so so offended and angry that I would use the word "boring". I spent the rest of the day trying to explain it and calm him down.
Anyway use caution with the word "boring". It's more toxic than nuance would suggest.
It's fun to dive in and "modernize all the things" - and certainly you can learn a lot in the process (perhaps at the expense of the business).
I don't believe that the only reasonable alternative to that is to "choose boring tech" though. Like so many things in life, it's very contextual, and this is where you need someone with a lot of background and war wounds who can discern valuable improvements from yet-another-CADT-library-rewrite. Sometimes they're hard to differentiate from an old crusty cynic though.
I'm resistant to either pole - I think there's often a 'middle way', where you can leverage proven, high-quality software (think PostgreSQL) while still benefiting from modern approaches (pragmatic functional idioms, etc). I'm old enough to remember when the industry was generally more entrenched in ossified approaches - it definitely has its downsides too!
The hard part is when a (supposedly) proven technology turns out to be a turd. Much of the job of choosing good tech appears to be using heuristics to avoid low quality tech with good marketing. I'd love to have better tools to guide that problem!
Great points. I was reminded about a period of close to ten years when “my stack” was Apache Tomcat with servlets and JSP. I would handle background tasks in threads initialized in servlet init methods. For me it was a universal platform for anything I was required to develop and deploy.
I was in Chicago last month and had breakfast with an old customer (I had never met him in person even though I did a ton of work for him between 2000 and 2006). One of my tasks for him was writing a Sharepoint clone that ran for five years totally unattended by his ops team. After five years they ran out of disk space and did a quick migration to a larger server. My customer thought that in five years they had never restarted to system or rebooted the server (yikes!, no security updates?).
[+] [-] oftenwrong|6 years ago|reply
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|6 years ago|reply
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'.
[+] [-] brightball|6 years ago|reply
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.
[+] [-] Datenstrom|6 years ago|reply
[+] [-] pif|6 years ago|reply
Actually, the rest of your comments points to: "Happiness comes from shipping good stuff"
[+] [-] parasubvert|6 years ago|reply
This is a great presentation, and great advice.
What this piece misses are the marketing, hiring practices and incentives in that capital pool that is fueling FOMO (fear of missing out) as the main driver of our technology trends.
Most people orbiting IT wants to be a part of something that changes the world: it’s their ticket to higher paying job elsewhere, bragging rights at a conference, internet fame/notoriety via blog posts, etc. This is how we wind up with Service Mesh proxied MongoDB on Kubernetes as THE ANSWER, and all the ensuing political battles / turf wars to fight boring alternatives as “yesterday’s news”.
It would be nice to see a greater focus on business outcomes, but I find few have the patience or bandwidth to truly track the success of a technology choice, unless you’re a larger company making a periodic cash bet with a business partner (eg software vendor). And even then, failure can be swept under the rug sometimes.
It requires strong leadership and management (or a great culture) to encourage your teams to communicate tradeoffs and make these sorts of “boring tech” decisions without it being more about individuals playing a turf game.
[+] [-] xwdv|6 years ago|reply
Every developer should spend some time working at the bleeding edge, so they know how it feels to get cut. The best time is absolutely at the beginning, when you’re a fresh grad and have the energy. You have the rest of your life to work on boring stuff that pays the bills, and who knows, if you are successful with a new technology early on, you might just be working on it for a very long time, continually breaking new grounds.
Choose bold technology early, then boring.
[+] [-] fogetti|6 years ago|reply
[+] [-] gfodor|6 years ago|reply
Also it seems to miss the point somewhat: choosing 'boring' technology has little to do with working on things that are unfulfilling. On the contrary, when tech stack choices are the thing from which developers derive their excitement from, in my view, it's often "empty calories" masking the lack of "emotional nutrition" they are getting from the problem they are solving or the users they are serving. For every whiz-bang neural network getting users to click on ads, there's a 'boring' embedded system running on an ancient C framework somewhere putting satellites in space. I'd rather work on the latter any day of the week.
As Hamming said, "if you're not working on the most important problem in your field, why not?"
[+] [-] delusional|6 years ago|reply
"Boring Technology" is the wrong thing to aim for. Aim for simplicity.
[+] [-] shapiro92|6 years ago|reply
[+] [-] tensor|6 years ago|reply
[+] [-] Daishiman|6 years ago|reply
A lot of new tech is shiny and provides legitimately useful benefits. Think the new wave of frameworks that started with Rails and Django.
There's a lot of shiny tech that has been a gigantic waste of everyone's time, like MongoDB and people trying to shoehorn MapReduce into every possible computation.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] samirm|6 years ago|reply
[+] [-] mastratton3|6 years ago|reply
If you want to work on new and exciting, you have to be willing to own the consequences and stay up late digging into the bugs, learning the ins and outs, and committing to delivering what you said would be delivered. </endrant>
TLDR: If you want to work on interesting, it'll take more commitment.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] dm3|6 years ago|reply
Great that he's spreading the word!
[+] [-] rb808|6 years ago|reply
Yeah I thought that until I had to look for a new job and my resume just had boring old technology on it. Now I make sure I do some padding!
[+] [-] tw1010|6 years ago|reply
[+] [-] esoterica|6 years ago|reply
[+] [-] agumonkey|6 years ago|reply
You can deliver so much more, so much safer using other techniques...
[+] [-] crispyambulance|6 years ago|reply
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 the problem at hand, we would be producing sad, boring things. If you want to see what that's like look at enterprise applications.
[+] [-] murgindrag|6 years ago|reply
[+] [-] rolltiide|6 years ago|reply
They are totally regional, programming-language subculture, and age related
The proponents of Atom/VSCode/Sublime/VIM etc will swear by it to the level of gatekeeping other competent software engineers away from them if they don't use that particular editor, and they all do - or can do - the same thing.
[+] [-] neilwilson|6 years ago|reply
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 to do it.
The marginal benefit of the new shiny is indeed an overhead you should try and avoid, but also you have to dodge the trap of being stuck in a technology when everybody else has moved on.
Anyway back to the Adabas support...
[+] [-] lvh|6 years ago|reply
(Overall this talk is fine! I think the problem/technology set illustration is particularly useful. I run Latacora's Cloud practice and we own all production infrastructure and "no, more boring, boringer than that, keep going" is a good way to describe what that looks like. We deploy half a dozen projects with exactly the same zero config storage and in ECS Fargate because I'm not managing servers.)
[+] [-] sydd|6 years ago|reply
[+] [-] jerf|6 years ago|reply
One of the places I'd say they are appropriate are in places where you have some problem where some "shiny-thing" stands head and shoulders above the "boring technology" in some particular and you can ram home those advantages well enough to overcome the other issues. For instance, if you've got a server where you're going to have several thousand clients opening a socket connection and babbling away at each other in some custom manner, starting with Erlang/Elixir is quite possibly a very good idea, because none of the "boring" tech is anywhere near as good at that, even today.
But I do agree that when doing the cost/benefit analyses of these choices, far too many developers plop an unprofessional amount of weight on the "benefit" side that amounts to "it's fun to play with the pretty-shiny". (I'm still recovering from some old "NoSQL" decisions made in a context where a relational database would have been more than adequate, at most backed by something that even at the time was tested like memcached, instead of a combination of what are now completely defunct and semi-defunct databases.)
[+] [-] bpyne|6 years ago|reply
"And when people succumb to this instinct they tell themselves that they’re giving developers freedom. And sure, it is freedom, but it's a very narrow definition of what freedom is."
Yup. You get the freedom to choose a language and/or database with unknowns but you lose the freedom to leave work at a reasonable hour to see your family, pursue a hobby, or just veg out. Experimenting with new (to your organization) languages and infrastructure pieces is something you do between projects, not during.
It reminds me of something a jazz musician said in an interview, "The audience doesn't pay to see you rehearse. Rehearsal is done on your own time away from audiences." Rehearsals are where you try new techniques, harmonies, instruments, etc.
[+] [-] 6chars|6 years ago|reply
[+] [-] sethc2|6 years ago|reply
My hope is for those who agree with the author's premise, that it is still using the same "boring" technology and more people switch to it, because over the last two years when we switched to use Typescript, it has gotten significantly more valuable as more and more people have used it because now a majority of the dependencies I take on have type definitions provided via DefinitelyTyped, or are included with the package.
[+] [-] yepguy|6 years ago|reply
It's less disruptive than putting a new language or database into production, and makes me significantly more content to work with a boring stack. Plus I get a more comfortable computing environment out of it.
Maybe someday I'll get Emacs just the way I like it, and need to find something else to distract me from chasing the new and shiny, but I kind of doubt it.
[+] [-] fogetti|6 years ago|reply
Well let me just add this:
> "Shortly after his release from the prison at Meung-sur-Loire he was arrested, in 1462, for robbery and detained at the Châtelet in Paris. He was freed on November 7 but was in prison the following year for his part in a brawl in the rue de la Parcheminerie. This time he was condemned to be pendu et etranglé (“hanged and strangled”). While under the sentence of death he wrote his superb “Ballade des pendus,” or “L’Épitaphe Villon”, in which he imagines himself hanging on the scaffold, his body rotting, and he makes a plea to God against the “justice” of men." - I wouldn't call that the highest step on the pyramid
[+] [-] kabes|6 years ago|reply
[+] [-] buboard|6 years ago|reply
[+] [-] rektomatic|6 years ago|reply
[+] [-] closeparen|6 years ago|reply
[+] [-] mcguire|6 years ago|reply
But,
"My friend Andrew wears the same brand of black shirt every day. He thinks that if he conserves the brainpower it would take to pick something to wear, he’ll bank it and be able to use it later for something else. [...] I like to think about it like this. Let’s say that we all get a limited number of innovation tokens to spend. [...] These represent our limited capacity to do something creative, or weird, or hard. We really don’t have that many of these to allocate. Early on in a company’s life, we get like maybe three. Not too many more than that."
I don't buy this. If you try to save up your brainpower, innovation tokens, intellectual capital, or whatever, what you'll find when you come to try to use it is that you don't have it. Sort of like if you try to save up your upper body strength for a couple of years before you try to climb El Capitan. But I am just saying that is a poor example.
[+] [-] redisman|6 years ago|reply
[+] [-] Balgair|6 years ago|reply
Tl;DR: Be disciplined, not motivated. Don't worry too much as well.
[+] [-] joaodlf|6 years ago|reply
Boring is boring but it simplifies so much. I still love new technology, but I am now much more likely to try it out extensively and privately before even dreaming of bringing it to my company. An example: A few years ago I got very excited about Go, I started introducing it at work and solved some difficult issues with it. I could not get the rest of the developers to gain an interest in the language, though. Effectively, no one else but me could touch any of that code, this is not good for business. I have now revamped that same code, using old technology, and learned a lot along the way - so much so that I now feel like this old tech behaves as nicely as the more complicated, flashy, new language implementation.
[+] [-] salixrosa|6 years ago|reply
The level of familiarity that can be achieved with a tool in the timeframe allotted before the "oh no, we're behind-the-times!" fervor strikes just doesn't seem sufficient to me. I'll have co-workers coming to me with the tool-specific roadblocks they're hitting, and have reached the point where I can easily say "yeah, I've been there, you'd never guess but the problem is with [X], just do [Y]." And just as I'm getting really efficient, I've got to throw it all out because that tool isn't cool anymore, and nobody wants to work with not-cool tools, and we've all got our resumes to worry about.
I wonder if there are some cultural changes that could help mitigate this. If there really is an endorphin rush when working with a fancy new tool, why is that there and what can we do to replace that? Is it resume-building, is it enjoyment of that stage of knowing-nothing, is it happiness when you easily do that one thing that was annoying the shit out of you with the old tool?
Can you pick apart why you were excited about and wanted to adopt Go?
[+] [-] dang|6 years ago|reply
[+] [-] TickleSteve|6 years ago|reply
The HN audience typically lives at the bleeding edge and assumes the world does too.
[+] [-] pqdbr|6 years ago|reply
[+] [-] ravenstine|6 years ago|reply
Better to work on something boring, but was carefully constructed over time and doesn't require 1/10 the dependencies of today's newfangled thing.
[+] [-] liveoneggs|6 years ago|reply
Anyway my boss got so so offended and angry that I would use the word "boring". I spent the rest of the day trying to explain it and calm him down.
Anyway use caution with the word "boring". It's more toxic than nuance would suggest.
[+] [-] switchbak|6 years ago|reply
I don't believe that the only reasonable alternative to that is to "choose boring tech" though. Like so many things in life, it's very contextual, and this is where you need someone with a lot of background and war wounds who can discern valuable improvements from yet-another-CADT-library-rewrite. Sometimes they're hard to differentiate from an old crusty cynic though.
I'm resistant to either pole - I think there's often a 'middle way', where you can leverage proven, high-quality software (think PostgreSQL) while still benefiting from modern approaches (pragmatic functional idioms, etc). I'm old enough to remember when the industry was generally more entrenched in ossified approaches - it definitely has its downsides too!
The hard part is when a (supposedly) proven technology turns out to be a turd. Much of the job of choosing good tech appears to be using heuristics to avoid low quality tech with good marketing. I'd love to have better tools to guide that problem!
[+] [-] mark_l_watson|6 years ago|reply
I was in Chicago last month and had breakfast with an old customer (I had never met him in person even though I did a ton of work for him between 2000 and 2006). One of my tasks for him was writing a Sharepoint clone that ran for five years totally unattended by his ops team. After five years they ran out of disk space and did a quick migration to a larger server. My customer thought that in five years they had never restarted to system or rebooted the server (yikes!, no security updates?).