Engineers need to be kept happy. Some like tech, some money. It's a personal preference.
Businessses need to deliver in-time and also profit, or they just need to be stable.
Choosing exciting can be a tech-debt, or it can remove tech debt.
Boring can be stable, but can be soul-crushing.
Exciting & Boring is not mutually exclusive. They can co-exist.
Engineer excitement and Business continuation must be kept in balance.
Generalization is not helpful. As an engineer or business, or in general a sensible person, you must always do pros and cons without bias.
Personally, I am excited (or satisfied) by systems that work, up to and including the processes required to keep it "in motion". The technology used is secondary as long as its properties and risks are understood and accounted for and you can work with it without having to double-check every little thing with the business owners or clients.
Sometimes things break, but in a "good" system, some breakage is expected, and the risk of breakage is not minimized by being fearful of change, but by having monitoring, redundancy and checks in place to keep the change controlled and the impact of faults within agreed boundaries.
>>> npm’s first Rust program hasn't caused any alerts in its year and a half in production. "My biggest compliment to Rust is that it's boring," offered Dickinson, "and this is an amazing compliment." The process of deploying the new Rust service was straightforward, and soon they were able to forget about the Rust service because it caused so few operational issues. At npm, the usual experience of deploying a JavaScript service to production was that the service would need extensive monitoring for errors and excessive resource usage necessitating debugging and restarts
That's actually what I'd call Elixir. "Excitingly boring". Built atop a runtime environment that is 35 years old, battle tested, and built for reliability in distributed and concurrent environments, but feeling like a modern, expressive language, with clever ideas that most other languages don't have.
Yep; I wasn't trying to counter anything said about Rust. At Discord? That's the only place I know of using both (and otherwise I feel like it'd be hard to have comparable overlap).
Considering caring for the happiness of your employees (or really people in general) to be infantilizing is a pretty toxic mindset IMO. I WANT MY JOB SOUL CRUSHING BECAUSE I'M A REAL MAN.
Happiness and entertainment are not the same thing. Most of us spend a huge portion of our life working, we might as well try to make it at least a little bit fulfilling instead of just a way to fund the two days of the week when you can do something else.
And more cynically happy people will almost certainly work better. Have you never taken much more time than necessary to complete a task just because it was so incredibly dull, tedious and uninteresting? Bugtrackers are filled with issues that would require two lines of code to fix but nobody can be bothered to write them.
I'm obviously not saying that you should purposefully treat employees like garbage. The parent comment's tone was as if a business needs to beg for workers, and to make sure that programmers are kept happy with fancy and trendy technology. This is what's toxic and infantilizing. We are all a part of a business for one purpose - to continue or increase the success of the business.
For me, a job has to be reciprocal. I take my salary very seriously, and I reflect on what I've done in the past pay period. I want to make sure that I've provided that amount of value in that amount of time. Of course my feelings are important, I'm not going to contribute to an environment that doesn't reciprocate the value that I provide with some combination of compensation and gratitude.
My point is, I hear a lot of programmers talk about the feelings of the business with disdain, and frankly complete entitlement. I've seen plenty of engineers not contribute their fair share value to the business side - they think they earn their living by showing up and completing a couple of tickets a week, when in reality the business needs are much more demanding. The ideal working relationship is reciprocal - both parties get some satisfying bit of value out of it.
> The parent comment's tone was as if a business needs to beg for workers, and to make sure that programmers are kept happy with fancy and trendy technology. This is what's toxic and infantilizing.
That was just your interpretation. The parent commenter said that some engineers are motivated by money and some by new tech. Either way you need to keep workers happy or they will leave, that is just common sense. So if you choose boring technology you will get people motivated by money and not the "infant" engineers who "need toys" as you say. But really they don't "need" the toys, they just prefer it and will therefore leave if someone else gives them that when you don't.
Employees are hired guns. Employees want a tolerable job and a good salary while the executives and owners want to maximize profits.
If programmers can act with “complete entitlement” sometimes it’s only because they are some of the few workers who can demand something from their jobs, even without a union backing them. Most workers do not have that privilege/leverage.
Happiness does not equal to entertainment. It's called job satisfaction, not specific to engineers.
Multiple factors can satisfy you. Pay is one of them. Some engineers can also take less pay in exchange for use of shiny tech because boring tech can be very demaning. But that's not always the case.
In either case, one need to be happy with job to continue right? Or else one can find another job if they are not happy with pay, organization, food, location, ethics, abuse etc. It's not 1-dimensional.
Happy people are more creative, and most engineering is definitely creative work. If most of your work is engaging or satisfying, it's easier to drudge through the bad bits.
It's not like physical work where you can just keep doing it and it'll resolve itself eventually; it is entirely possible to keep hitting your head against an engineering problem forever without making any progress if your brain just refuses to make the correct connections, and it's really difficult to tell if you're making progress or not.
In general, all people deserve to be kept happy, so removing barriers to happiness is nearly always a good thing.
> The alternative to this is offering more money, which isn’t even guaranteed to work.
This is true, but I feel misses the mark a little.
The absolute best development job I've had in my 15 odd years of experience was my first job. It wasn't about the technology. What I was using there was completely new to me, down to the text editor and keyboard (vim + Microsoft Natural ergonomic, you should have seen me struggling to do anything learning both at once). It wasn't about the pay. The company was paying an embarrassingly low rate because they were one of two companies in town hiring developers. It wasn't because we had a fancy office or a stocked pantry or beer on tap. We had none of that.
No. It was entirely because of the people I worked with. We would all play World of Warcraft after hours. We would joke around at work during the day and eat lunch together.
That's it. That's the entire secret to a happy job. And you can't bottle that magic sauce up and sell it at trade shows and conferences. You can't write a book on it. Because it's situational. If you've ever worked at a place like that, then you know what I'm talking about. It has little to do with the company. In fact, the CEO was a bit of a narcissistic slimey toad.
Businesses spend a fortune trying to force such an environment through cargo cult. "If we provide X, then developers will show up and work all night." So every company is a "campus" that resembles a college dorm environment. And it all falls flat and infantile. Because we are adults and see it as the pandering it is.
I disagree that employees need to be kept happy. The confident/ well informed ones do if you want them to stay, because they will go spend the extra time to leave and find another job. But I've been in jobs where developers are clearly not happy, but they put up with it.
So the point is, you will brain drain your company if you don't make developers happy.
I was initially gonna say "Good" in place of "confident/ well informed", but I'm sure some developers who are good simply don't know there are better places out for them.
Yes thats what I was trying to explain. I didn't know the name was dead sea effect. I don't recommend doing this, I just mean employees don't "need" to be kept happy, many companies exist like this, and some do quite well financially. I guess the dead sea effect doesn't always happen.
I’m not saying you should abuse employees. It’s pretty weird how much we think engineers need to be coddled and kept engaged though. First of all, if you have to consciously think about this, your company probably isn’t engaging to begin with. Second, you need to work to eat. I think people forget that sometimes.
I resent that. The difference between pure privilege and entitlement is that, when you are entitled, you expect your privilege and don't acknowledge what you should be reciprocating for it.
That's what made me react so strongly to this comment. I think we should have more gratitude for our privilege.
> I think we should have more gratitude for our privilege.
The company hired you because you make them money. As soon as the company feels you are a bad deal they will fire you. Why shouldn't you do the same to them? Feeling gratitude about a shitty job will just make shitty jobs more common, that isn't good for anyone.
Sure, maybe to other people in the world who are not as privileged, but help keep society tick anyway. We can be grateful to them that their toil is allowing us to spend our time doing this. But like the sibling comment said, employment is a business transaction, even if it’s usually heavily lopsided in favor of the employer. Typically it’s an organization owned and run by people who are even more privileged than us, and that don’t have any qualms about applying pressure in the other direction when they can (see the working conditions of most of the aforementioned ”other people in the world”).
Of course we should be respectful and strive to do our best and provide value commensurate with our compensation. But if the market is such that people can take a pick and go to companies that let them have more fun while doing so, I think that’s great. It’s a pretty calvinistic mindset to see it otherwise.
Having the opportunity to change jobs because you might be happier, more fulfilled or better paid somewhere else is neither privilege nor entitlement. It's pretty much a sacred right. Every single job should be like this.
The decision to "coddle" and "engage" engineers is made by companies. It's their choice, and their strategy. I would even argue that this is not even close to what engineers prefer: most would definitely choose a raise, or decreased number of hours over the "happiness" thing.
They’re professionals whose decisions and input companies must afford the appropriate amount of consideration, and whose professional development companies must also respect to be competitive in the hiring market. These tech choices are usually contextual, and that context includes business factors such as continuity and retention, which present a trade off. That is a compressed version of the GP post.
> What is this idea that “engineers need to be kept happy?”
Are you honestly asking why people who happen to have a profession need to be happy?
And what's this idea that happiness is something that is only desirable in children? Do you honestly believe everyone should be cursed to die inside once they enter adulthood?
A healthy society is a society where happiness is not an abnormality, but the norm.
I'm not against happiness. Read the wording of that statement:
"Engineers need to be kept happy."
This is a statement rooted in fear - that if you don't entertain programmers with things that they enjoy, they will leave. Does that not sound like how you'd approach a child who you fear will have a tantrum if you don't give them a lollipop?
I'm saying, programmers also need to take pride and satisfaction in the contribution they make to a business. Focusing on the business outcomes that you contribute to is more satisfying than getting to use React at work, or whatever it is you think will keep you "happy."
I'm talking specifically about the idea that programmers conflate tech stacks with happiness, not happiness in general. I would hope that was clear.
> This is a statement rooted in fear - that if you don't entertain programmers with things that they enjoy, they will leave.
This is not a matter of "entertaining" engineers. This is a problem of providing good or even decent working conditions. High stress and high churn work environments have high attrition, because when given a choice adults prefer not to be miserable.
You're pretending that this issue is all about pampering when at it's core there are poor work environments that needlessly cause mental problems, some of them permanent.
Are we supposed to pretend that there was at least one FANG, supposedly a group of companies known for being generous to it's employees, which a few years ago was known for having employees crying at their desks?
A lot of people are missing a nuance. Should employees take satisfaction in what they creating, what the business is selling to customers, and how they're advancing in their careers/learning? Of course.
Does that mean that the business should allow developers to indulge in whatever resume-driven development decisions they feel like lest they burst into tears? No. There are various comments in the thread about people who get bored after a few months because they have to do code maintenance.
> There are various comments in the thread about people who get bored after a few months because they have to do code maintenance.
There is nothing wrong with getting bored by maintenance work. If you have that kind of work then hire boring engineers who will do whatever as long as you give them money, but don't say that all engineers needs to be happy with that kind of work.
There is that, but mostly the concern of many engineers is that they need to stay buzzword-compliant to have a marketable resume, otherwise they risk career stagnation. It's an indictment of hiring managers, and to an extent a self-fulfilling prophecy, but we all know the best technology does not always win in the marketplace.
It's more about avoiding avoiding negative emotions being associated with the work in a way which does hamper productivity.
Software Development is that strange split between clear defined engineering aspects and creativity aspects which are often as important.
I have seen major problems in projects due to developers being dissatisfied and annoyed with the tools they can use.
The problem was twofold
- first it was not that they couldn't use the newest exiting tools, but that the tools they had to use had horrible UX making them unnecessary hard to use. Like if you tell someone they have to now turn pages of an book with a fork instead of their hands.
- The other problem was that one person involved had a fixed view about what is good and in their view must be done and nothing else is good and doing something else is always stupid and as such in their view their work is stupid and worthless and as such they don't want to do that at all as it's just a pointless wast of time which will be discarded in the future anyway... Which is quite a bad approach to your job, tbh. And caused some massive problems later on.
Nope. Their are humans. And (seeking) happiness is one of the most powerful motivators (if not THE most powerful one) for such beings.
Also, happy people just produce better results. Especially if the way for them to achieve happiness is the route to better results. If you just want your coal mined, happiness of your workers may not matter much. As soon as you want quality output from any intellectual worker it will start to matter. (Though I'm pretty sure that it's true for any job with any level of autonomy and creativity needed, even if it's manual labour.)
Contrary to what some seem to think, for most people, getting a new well-paying job isn't a matter of sending a couple of emails and starting somewhere else for the same or more money the following Monday. I've been unhappy, for certain values of unhappy, for periods at probably every one of the handful of jobs I've had over the years. I've either worked through it or I've switched jobs. But it's never been something I've done casually.
Yeah, you don't have to make people without options happy, you are right. But I wouldn't want to work at a company that accumulates engineers without options.
If I have to do a Magento project I charge double.
If I knew COBOL I would charge even more.
Simply put, if the job is not enjoyable I'd rather look for an enjoyable job or ask more money until it's worth it.
The market still favours developers and finding a job is pretty easy, so developers have all the incentive to look for a fulfilling position, while it lasts.
I'd be quite happy to show up, build something, and then keep it producing value for customers for decades with as little time and effort for all the humans involved as possible.
As long as there is a way to quantify that value, it could be incentivized, boring systems should be the most profitable.
It's a reality that retaining developers in the US sometimes involves indulging their pet projects despite negative expected value. In other parts of the world, many capable developers are happy to just have reliable, reasonably paid work. There may be a correction coming.
It's not. But there are definitely people commenting who, for them, seem to feel that "happy" equals, at least in part, playing with cool new stuff. Which is obviously a valid preference. They just shouldn't be surprised if most companies won't be open to people flitting from thing to thing, getting bored every few months.
In many cases, in some industries: yes. When working in media production, it does not matter if the media being produced is feature films, feature animated films, a TV series, an animated TV series, or a AAA to C level video game production - the software developers, digital artists, and line producers are ready to quit or reduce productivity to a trickle at the drop of a hat if they sense the production will not be a commercial success and not grant them social bragging rights. Yes, this sounds completely absurd, until you are in the media production industries and see it happening. It's an entitled attitude, but getting the line workers to see it that way is not gonna happen.
> It's an entitled attitude, but getting the line workers to see it that way is not gonna happen.
Not it is not. Knowing you can get a better job elsewhere and therefore going elsewhere is not entitlement. Thinking that workers who are unhappy and can get a better job elsewhere shouldn't leave is entitlement.
If the company really provides value the employee wont leave just to work on a new framework. If your employee leaves you simply didn't provide enough value to them.
Yeah the confusion is caused by people meaning stable & tested when they say boring, as they find most of the stuff that excites people not suitable for production use. There's still a lot remaining though, when you filter out the unstable and untested stuff.
I agree that the very talented engineers need to be challenged and kept happy, but with a balance: sometimes stuff needs to get done and somebody will have to do it. The other thing one needs to be careful of is if they start challenging themselves by writing very complex and difficult to maintain code.
Engineers who find a stable technology boring after a few years probably lack curiosity and are not digging deep enough. It's a form of ADHD.
After almost a decade, I still find lots of interesting ways to write plain vanilla JS code that makes developer's jobs easier in lots of interesting ways. Before that, I spent a full decade writing C++ using nothing but a restricted set of in-house libraries. I don't recall ever being bored because I always felt like a carpenter: have a problem? You have the tools to build more tools to make your life easier. I experimented with event driven models vs. streams vs. queues, doing complex calculations by spreading them across the nodes of a tree, developing unit and API test tools (C++ had none, many years ago).
Today, architecture feels more like technology shopping than tinkering.
FYI using the terms ADHD/ADD when not talking about the actual disorder is often offensive to people who have ADHD. It fails to acknowledge that the condition is more complicated than just getting bored quickly, especially when your statement can be interpreted as implying that people with ADHD "lack curiosity and are not digging deep enough". Things are hard enough for people with ADHD without trivialising/generalising/moralising their problems.
I totally agree with you, I've been writing professionally php and python, vanilla js/react and postgresql for a good decade now and I'm still learning exciting new things in these technology.
(Note on the side I've made weekend projects in Rust, tested Cassandra, Kafka)
I think one should have a toolbox with proven tools that should be default tools, while keeping an hygiene of testing new tools so that when the day arise that either the "new tool" survive the test of time, or you encounter a problematic that is really solvable only with that new tech, you can make an exception.
I do the same thing. I write at least a hello world project in most new tech that comes my way. Sometimes I find some of them interesting and use them in production maybe a year or two later. But definitely not as soon as I learn them!
I write mostly HTML 3.2 (with progressive enhancement additions on top for newer browsers) and I'm still finding new things to do with it after 20+ years.
JS script too. I've never been bored by JS because there were always multiple clever ways to do things, and I had to figure the way that was sufficiently clever to make my and my teammates lives easier, but not so clever it made our lives harder.
Java is boring because invariably I spend all that time trying to figure out the one way to make things work, given that the thing I need to do involves a library that abstracts everything multiple levels deep and all I have are API Javadocs that describe how various abstractions get created via constructors and factories that take -other- abstractions, that have no meaning whatsoever to me and my problem domain. Which means I spend hours to figure out how to do the simplest things, and I'm mentally unstimulated the entire time.
No, I'm not. I'm familiar with the curse (it's referenced extensively, and even influences the title, of Pratchett's "Interesting Times"). I'm even making a similar statement with my comments on JS; hence why "too clever" is a bad thing.
That all may be true, but that's unfortunately the state of the market. If you want to keep developers, you need to be cognizant of this fact and adjust accordingly.
"Today, architecture feels more like technology shopping than tinkering."
That's because most web development jobs are maintaining glorified CRUD applications. Real actual software engineering jobs are hard to find, and don't pay as well as web development (or it's open source software that doesn't pay).
First of all, this is a typical example of survivorship bias: look, we picked exciting tech and we've succeeded. The point of using 'boring tech' was never to state that everyone should stay away from new/exciting things. It's about managing risks. First of all, if you are building a startup, a new service, you already have a ton of risks and unknowns (and excitement) so it makes little sense to top it with untested, new, exciting technology. Unless you have a very good reason. (And no, anticipating to have a huge number of users X years down the road and the perceived need need for super scalability is not a good reason.)
The point about using more new tech being good for the adoption of these might be a fair one, but it's completely orthogonal and doesn't need to happen in startups and definitely not at the core of their service/product. Once you do know what you are doing (or what you re doing is not that important) then it's OK to pick exciting technology.
Feels like this person completely missed the point of choose boring technology. The point isn't to never use anything new or exciting, the point is to save the excitement for your core value prop so that you're not wasting time e.g. debugging why your customer database keeps losing data instead of iterating on your actual product, where all the excitement is.
Agreed. Their example is that selecting Elixir was a great choice for them. Cool. That was using an Innovation Token.
I'm guessing that in addition to Elixir, they also used plenty of boring technology. Like using `cron` or `at` rather than writing your own scheduling subsystem. Or building on top of a standard OSS database rather than rolling their own.
The point isn't to _never_ to use new technology, but rather to use enough boring tech that you still have mental bandwidth to pour into the new tech, innovation, or product that will be your competitive edge.
A technological aside that's neither here nor there with regards to the broader 'boring' debate: one of the advantages of Erlang/Elixir is that it's more of a self-contained ecosystem than, say, Rails, where you can run a bunch of different "applications" inside the same process, and it's easy for them to talk to one another. There are a number of 'cron' type things that you can easily run within your BEAM system. For some kinds of applications and deployments, this is pretty convenient. It's easier to create jobs programmatically, to introspect them, and to keep track of them all within the same system, without an external dependency.
Both this and the other post trending on HN right now about boring technology show yet again that the Internet is a place for polarising views and clickbait titles rather than sensible discussion.
I'm not really sure why you think these articles are not contributing to sensible discussion. Both articles provide arguments for their case, neither seem dogmatic about it.
In contrast, your comment offers no arguments, you merely dismiss the debate as uninteresting, while simultaneously misunderstanding what these authors are talking about: you claim one should simply "choose the right tech for the job", as if there is always an obvious right choice. But it seems pretty clear to me that both authors agree that this is in fact often a hard choice.
And both articles are about such situations: what to do if the choice between multiple technologies is hard. In reality, you can almost never really evaluate all the alternatives, so you need some sort of "reasoned bias", a heuristic that helps you decide between candidates. "Choose boring technology" and "choose exciting technology" are both suggestions for such heuristics.
This is exactly what I intended to do when publishing this article: provoke sensible discussion. I think it's valuable to talk about polarizing views. Often agreement solely depends on the context you are in and it's useful to get familiar with different contexts.
The bridge between polarizing views is in the comments. Comments are the last bastion of honest discussion, and it’s why people don’t bother reading articles. A good article is one that spawns good comments, and sometimes all you need is a good headline to spur the discussion.
Has anyone ever argued against using the right tool for the job? That advice is unfortunately not very actionable. The whole discussion is about which tool is right for which job.
I have worked for several startups as a Python engineer and the job always follows this pattern:
1) I am brought in to work on some interesting project that has a mix of exciting and boring technologies. I mostly work on exciting stuff. This honey moon phase lasts from several weeks to several months.
2) As the project starts to mature, management start to demand more and more unrelated maintenance work from the team members.
At this point my time is roughly spent 50/50 on developing new features, and things like fixing spaghetti that somebody wrote years ago. I call this type of work firefighting, since management talk about it like a codebase has caught fire.
3) Management find out that projects that were on fire are seriously damaged despite not being on fire anymore. As more and more defects are found, my job gets dangerously close to being 90% boring.
4) At this point the team members that once worked on an exciting project are considered experts in random legacy codebases, and their job is extremely boring since it mostly involves maintaining them.
Personally, I find myself reading code on Github, reading HN, etc. basically trying to keep up with what's happening out there. I'm ready to move on to a project where I can learn something.
Sorry to ask this, but there's one common thread in your experiences which "always" follow this pattern: you were one of the engineers on them. Do you have any evidence that you're not the problem here?
I believe there is a teapot (too small to be detected) orbiting the Sun between the Earth and Mars, and no one has been able to disprove it. Don't quote me on this though.
I'd just like to make sure you've at least considered the hypothesis your words are strongly suggesting, namely that you specialise in producing tech debt and you quit whenever that debt crosses some critical threshold. If it's not actually like that, then great!
In my experience, startups produce enough tech debt very early in their existence, that if candidates knew about it, they would simply opt out of the hiring process and focus on something else.
So what they do is lure engineers with greenfield projects or projects that are relatively healthy and have a good architecture, and are currently growing. Once these projects have been developed or expanded to a point where the engineers in charge (new hires among them) can also work on other stuff, the shift to "firefighting tasks" and legacy maintenance can be quite fast.
To be fair, for a backend engineer it's not that brutal, our stuff is relatively homogenous (our legacy stuff also sucks, but not that much). When it comes to frontend development though, I have seen coworkers transition from clean Vue codebases to massive jQuery spaghetti balls in just a few days.
For me, at this point, using exciting technology is like writing a book on exciting paper.
I'm not interested in any framework with a philosophy, any language with a fan club, or any library with an opinion of how I should be doing my job.
I want to use "technology" that works and stays out of the way so I can build useful things. That's where the excitement is -- in the stuff I'm building.
This reason is why I don’t get along well with most frameworks.
Most frameworks are infuriatingly self-interested. They’re so intent on telling me that their imposed architecture is superior, despite knowing nothing about how I’m using it.
And then there’s the social pressure to use tech that specifically aims to make devs interchangeable.
>And then there’s the social pressure to use tech that specifically aims to make devs interchangeable.
Everyone has an interest in a degree of interchangeability. How mobile do you think developers would be in a world where it took them a year to get up to speed on a new set of tooling, languages, frameworks, etc. every time they switched jobs?
I have problems with the idea that devs really should spend most of their time coloring by number rather than amassing domain knowledge and expertise in the craft of development.
The textbook used in a digital electronics design course I took in college in the early '80s ended with a section called "The Engineer as Dope Pusher".
It gave an example of clothes dryers. The way most clothes dryers worked at the time is that you told them how long to run and how hot to get. The "how long to run" part was handled by a simple mechanical clock mechanism. You turned a dial to indicate how long you wanted it to run. Thus directly set the clock. You started the dryer, the clock ticked down, the dial moved back toward the original position, and when it got there the dryer stopped.
Those clock mechanism designs were several decades old. They were mass produced, very reliable, very cheap, and when one did broke the repairperson could easily replace it with one from a different manufacturer. Different models might have different mounting brackets, but it was easy for a repairman to improvise something if they didn't happen to have one on hand with the right bracket.
They were also extremely easy for consumers to use.
But they are also boring for the dryer designers. So there were dryer designers out there, the author said, who were starting to design their new dryers with digital timers.
Digital was exciting. The engineer got to play with microprocessors which were new at the time. They got to design printed circuit boards, a power supply for the digital electronics [1], a display, a keypad for input. They got to play around with programming the microprocessor.
But to the consumer that digital dryer control wasn't better. It didn't offer any functionality that the mechanical clock interface did not. It had a much worse interface usually. It was less reliable. It cost more, so when it did break the consumer was looking at a more expensive repair, and a slower repair since the repairperson had to get that specific control unit.
The point was that the engineer should not let their desire to play around with new and fun things take priority over delivering the best solution to the customer. There are places where digital is better than the old way--if you want to play with digital you should work on those projects, not shove digital into places where it is worse.
[1] The mechanical timers were either powered by a spring that was wound up when you turned the dial, or a simple electric motor that just needed a transformer to power it from the AC and maybe a rectifier.
More like an example of short-sightedness. Sure mechanical spring is better but having digital interface allows for complex dryer timing logic and optimisations.
If someone decides to make a dryer with complex logic and optimizations then digital would be the better solution for the consumer.
The author was talking about dryers that had no functionality beyond what the ones with the mechanical timers had. They were digital just because that was more interesting to the dryer engineer.
The problem, I believe, is in the word "exciting". It's simply too broad to make reasonable generalizations about. Exciting technology to one person might be sorting a text file, to another person it might be creating a GAN dapp.
If other people have to use and maintain this thing we find exciting, it stands to reason that perhaps they might not find it so exciting. If social media has taught us anything, is that interactions with UXs that give us dopamine hits may not be in our own or others' best interest over the long run.
I like "make cool stuff". The focus is on the goal, not the step-by-step interaction. It directs us to the outside, where our code interacts with people, be it users or future code maintainers. It's also vague enough that all sorts of people can define it as they like.
I love exciting new tech and having fun developing. I just don't define that love by how it makes me feel. Instead, I balance how it makes me feel and how it makes others feel too. That leads to a lot of even more interesting and fun places than simply "choose exciting technology"
ADD: Put differently, you always want your goal to "pull" the required complexity out of a system. It's a forcing function. It never works well when you start with a bunch of complexity and try to push it all towards a goal. That's backwards. I think we've sold a lot of developers on the idea that with a cool enough X, they're bound to make cool things for others. After all, look how cool X is!
I don't get this whole debate. Who decides what is boring and what is exciting technology?
Kubernetes can be pretty boring for somebody who worked with it for years, but an exciting, eye-opening experience for a team who has no experience with it. MySQL can also be exciting if you have only worked with Excel in the past. NoSQL can be exciting, but it can also be a safe bet if you need a multi master db, because your app needs to work offline.
I think it's easy to say a technology is safe or risky to easily promote or dismiss it. But in fact it makes sense to study and experiment with both boring and exciting technology to know if it might make your work easier and your results better.
I liked this article and I feel there is validity to the point that innovation can be stifled by strictly choosing boring technology.
But it is worth mentioning that in any non-trivial project there isn't a single "Choose Boring" or "Choose Exciting" technology decision that is made. Rather there is an entire collection of these types of decisions. And since "Choose Exciting" typically means that the tech is unfamiliar and/or novel, project risk dramatically increases the more "Choose Exciting" choices that are made.
As a tech person, and as a manager of engineers who I want to keep engaged and motivated, I have an affinity towards the "exciting" choices. But as the person responsible for on-schedule, on-budget delivery, I get pulled back towards "boring". It is a careful balancing act.
This is an interesting question. Some thoughts in no particular order:
I think a lot of engineers, are, by nature, curious to learn, try new things and experiment.
If you're doing the same thing over and over, it's not making that part of your brain happy.
You can do new and interesting things with "boring technology".
Sometimes, the new thing is worthwhile. I remember when Rails was new. I'm glad I picked it up, and still think it's a very, very solid way of getting things done in a way that's both rapid, and yet generally well organized and with a propensity for testing and a culture of writing good code. At the time, there was a lot of PHP, which was quick... but often a mess. There were Java frameworks, but they were big and heavy and clunky. At this point, both those languages have benefited from some of the ideas in Rails.
It's important to try and figure out what the "sweet spot" is for the new tech if you want to use it. As someone who has used Erlang for a long time, including professionally, I've been curious about doing some work with Elixir, but there are definitely places out there who employed it because "new", it seems, without solid reasons why. I'm still not 100% sure what the sweet spot is for Elixir, although I was very happy with Erlang for the "semi-embedded" systems where I used it.
I think going for one or two new things, while keeping the rest mostly the same is a decent way of containing the risk. I've been using Postgres for 20+ years, quite happily. I enjoy the challenge of writing solid, performant queries with it, but it's the same DB system.
- most "exiting" tech is not a innovation. It's just rehashing long known and previously failed concepts in new clothes. And sure due to improved UX, computation capabilities and/or better engineering it now might succeed or well just fail again.
- most companies purpose is to create revenue (hopefully by creating a good product). So there isn't any interest to drive innovation if everything can be done completely fine with existing tech.
- Just using new tech doesn't necessary drive innovation, only by giving useful feedback can it drive innovation. Something which in my experience is often not done, especially in smaller startups.
- If exiting tech enables you to do thinks you couldn't do before or to do thinks much more efficient (mainly productivity wise) then sure go ahead and use it but in my experience for a lot of companies opting to use exiting tech it's not the case at all.
- Not all exiting tech fits all company sizes, there is quite a lot of exiting tech which is generally good but at some point as a massive major overhead. Which any massive company can handle but which makes it a horrible choice for smaller companies.
- Lastly some exiting tech is not just not innovation it's more like de-inovation and the only good think it has going for it is that it easy to get started with and "is fun"/"exiting" or similar.
So I would only use exiting tech if it gives you a good benefit over other tech you can use instead.
Be aware that better UX can totally be a benefit good enough to make it worth it. (With UX I mean the developer experience as the developer is the direct user of the tech.)
The goal should be to maximize the amount of solution space that can be explored, and them maintained, for a given amount of effort.
Use your spiffy new stuff to prove something is possible, to build that MVP. Then use something reliable to implement production version.
You can use a fancy million dollar CNC machine to build the engineering prototype of a gear set... but you're going to end up using some old as the hills Gleason or Barber-Coleman machines to make them in production quantities.
The CNC machine lets you iterate through the design space almost instantly... the gear cutting machines take a few hours each setup, but then produce gears much, MUCH faster than the CNC machine in actual production. They've been optimized to do so.
Interesting take, but within software, isn't using brand new tech that you need to learn (plus has less documentation, ecosystem, community, etc) slower for iteration?
The spiffy new language usually has some feature the developer can use to save time making the prototype. Since long term maintenance isn't an issue, you are free to iterate until it works.
Stable platforms that you have experience on are well known, and your estimates of doing X on them are far more likely to be accurate.
Choose boring technology, and every other person can copy your work.
Choose exciting new technology, you will be able to have features that few can replicate, or it will take them more time to do so.
The question should be, are the features you need important for your business or have a supporting role only? U dont need to re-invent the wheel and use the greatest and latest to run a database. But u definitely need to have a cutting edge feature that others will have tough time building.
Search for the late Christensen Clayton, who quoted "disruptive technologies". He has many youtubes great for a Sunday.
How do you think the field of carpentry feels about this? Do you think they tell young carpenters in the field to convince homeowners to build their next closet in clay, because wood is old and boring?
Yes, there’s actually a really similar throughline.
My dad’s been a joiner for 40+ years. At the time he started, the industry didn’t have access to things like MDF, cordless drills, nailguns, or various other tools and materials that are now taken for granted.
The general principle that he’s expressed to me—and one I’ve tried to follow—is that it’s worth investing in and keeping an eye on developments and new technology, and applying them in situations where you are confident they will offer a benefit. That might be faster completion of a job, or lower-cost materials, or a more robust outcome.
Jumping in to using new techniques “just because” is usually a bad idea, though sometimes it’s worth doing so in less critical situations to make sure your skills and knowledge are up to date. The flip-side is he mentioned a case where he’d hired someone experienced and sent them off to do something—I think sheeting a floor with plywood or something—and came back at the end of the day to find they’d spent the day trying to do the job with a hand drill instead of an electronic drill.
I’d say the balance is what is important. Boring technology is a good basis to start with and is usually the right choice, because most problems are boring. But this shouldn’t prevent you from applying exciting technology in cases where it offers a genuine benefit. Just be aware that excitement has a cost, and you have limited “excitement tokens” that you are able to spend, so it’s best to save them for the bits where they offer a real benefit.
Yes? Well maybe not clay, but the choice of materials is certainly subject to cycles and hype. See bioconcrete for instance these days for construction in general.
This is a great comment, but I would generalize to just about any other profession. Are nurses bored with bandaids and hoping for better technology? And also comparisons between computer engineering and construction are always problematic because they are at completely different stages of maturity. Maybe what you suggest did happen in 1500 BC when the homeowner was like "Hey buddy, just build this closet with mud bricks" and the carpenter was like "Nar bro, I got these twigs I cut down that are super cool. Mud is for neubs".
Bandaids, I don't know, but they (at least some) certainly are about new sensors/techniques/catheters,... Also, people wanting to work on the latest and greatest because it is the latest and greatest is also sometimes an issue.
"Choose boring tech" doesn't mean you should never try something new and fun. It means you limit those new things to a few. The original article speaks of innovation tokens.
Erlang and BEAM are an interesting one in the "boring" to "exciting" spectrum, being quite mature and stable with a strong track record of successful large systems built on it, yet I'd imagine still considered exotic to the majority of developers out there cranking away on "boring" languages.
How so? I've switched back and forth between Erlang and Rails at various companies. I still find Ruby a great way to get things done quickly and cleanly. I haven't used Elixir quite as much. It's a nice language, and I think genuinely improves on Erlang in some ways, but it's more the BEAM system that I like about it rather than it being a lot more productive than Ruby.
> Don’t follow rules of thumb blindly. If excitement drives you, you are not alone.
In my experience, few things are as exciting as shipping. Watching people use the code I wrote, or turning a mature, battle-tested infrastructure over to a new team, and watching them take it to the stratosphere.
And not having to create a JIRA database for bug reports, because the quality is so high that an occasional email is all you get.
No...scratch that. Failing is also quite exciting. Not what you meant? Sorry about that.
I'm not a big fan of dogma. That includes "Use the latest <BUZZWORD DU JOUR>, or you're a loser," as well as "Stay the hell away from the latest <BUZZWORD DU JOUR>, or you might get hurt."
I write in Swift. Even though it is coming up on seven years old, it's still a baby, compared to languages like Rust and Python. I committed to using it, the day it was announced.
This was because the company that supported it (you may have heard of them) was demonstrably behind the language, and the guy that designed it, wrote LLVM, so I knew it had a future.
I feel like I have really only been good enough at it to be confident, for the last couple of years, despite shipping a number of apps, written in it, since 2014.
I write in PHP, because I don't like to spend too much time on the server end of the API, and want solid, reliable and supported tech on the backend. If I want something more "cutting edge," I'll hire someone that is more familiar with that tech, as opposed to trying to learn it, myself.
I agree 100%, but you also need to know which tech is going to get mainstream later on. Nobody wants to use tech which was once exciting, and now deprecated.
I took several bets with frameworks, libraries, databases and even languages during my career. Most of them worked out great. Only one time I needed to rewrite stuff because some library got deprecated. Overall it was well worth it.
The point is not to always choose boring technology. The useful concept are the innovation tokens. If you spent your innovation tokens on other stuff (org change, process change, new customer, new product), then you should at least keep the tech stable. Otherwise, feel free to invest some innovation tokens into exciting technology.
Ya know what is super duper exciting? Finding a boring product/service area no one is exploiting and you can design the entire experience for customers, infrastructure, and partners and reap all the profits. That's exciting.
A metaphor I use that seems to help me cut through some nonsense is that computer systems are factories.
From that POV most of what we do in the IT field is unspeakably ridiculous. Our machines are Fractal Rube Goldberg machines made out of Rube Goldberg machines.
- - - -
Elixir is a bad example, it's "boring" not "exciting". It's a thin syntactic layer over the BEAM, which is for running telephony exchanges. Those things could not be more "boring" in the sense we're using here: they just sit there and work, day in and day out, tolerating faults and load variances, routing phone calls.
I used to always get excited over new tools, but stopped because if they don't solve a type of problem I must or want to solve, it's just not that interesting. Algorithms, data structures, design decisions and methods (with their limitations), business domains I develop towards, and choosing what to solve end up be more interesting. I started to look at Rust, for example, for at most a few days, but I am not solving anything that needs it at the moment, but can understand why it exists at least.
But, if you can use something new and shiny, great. I rarely had that opportunity myself.
Technology is just a tool like a spoon.
It is uninteresting and boring on its own account.
As an engineer what you can achieve, what you produce should excite you, what you produce, something that is useful and used. Something important. The product.
Technology is just an aspect to achoeve it. One of many. It can be exciting, it can be boring, but the ultimate excitement is the creation of something useful, not using a tool...
If the tool has the focus that is more like entertainment. Not engineering.
Use whatever you need, boring or exciting alike!
Let the task and the product excite you, not the tools.
Over and over again I hear from friends who work at companies that chose exciting technology that a major benefit is that it makes it easy to hire talented engineers who are exceptionally good, because that’s who’s interested in learning the exciting tech—and for startups this can mean being able to afford a top-notch engineer when they otherwise might not.
And over and over again I hear from companies that use boring tech that it’s extremely hard to hire top people and so they hire junior people and hope to turn them into senior people.
As I see it, choose boring tech where stability is paramount, i.e. at work. Opt for fancy new stuff when you want to learn, i.e. at home.
The first will let you honor your moral contract of service quality with your clients.
The latter will enable you to grow and experiment in a low-stakes environment. Also, when the new toys become boring, you'll be The Guru (tm) everyone goes to for advice.
You're happy, and everyone wins.
Edit: of course 'work' and 'home' are used loosely here, not taking into account real-world diversity.
I think part of what’s weird about this discussion is that the usage of “boring” or “exciting” is somewhat misapplied. What’s apparently the distinguishing property is “common” or “familiar” vs “exotic” or “novel”.
But neither of those positions necessarily contradicts the other’s stated goals. Familiar technology can certainly be exciting to work with, and unfamiliar technology can be used for pure dull getting stuff done.
You've got it half right, the term "exciting" is being used for "exotic" or "novel" (and note that these are subjective: they depend on the history of the speaker) while "boring" means something more like "reliable" or "low-maintenance" (which is much less subjective and can be more-or-less measured and quantified in hard data.)
In any event, the crux of the issue is how your tech handles failures. A new-fangled exotic technology that works really well is "boring". Case in point: Elm lang. Very exotic, totally boring.
You’re restating my point in slightly different words. The reason that I addressed the “boring” side the way I did is because it’s so often used reflexively to discourage use of newer/more exotic tech like Elm without acknowledging that it is, in fact, “boring” in the intended sense.
Wow, from Aug 2004: "And people don't learn [Python] because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know."
Elixir seems to be quite pragmatic choice despite being a niche tool (most Erlang OTP pros and cons are is still there).
Rust has already passed point of no return by gaining so much support (and hype) in the industry. I almost feel like it can hurt it. Too many articles here like "Some_random_foo implemented in Rust" look almost as "How some_random_bar will be revolutionized with blockchain."
So a good equivalent to that article's Python example is something simple, not very bloated that people might enjoy for rapid prototyping or for side projects. And at the same time not popular enough to have an army of newcomers or hundreds of "boring" jobs. Various FP languages set the bar to high to match these criteria. If there is such a language now, we'll know that for sure in 10 years.
I think boring/exciting are a matter of context, some new tech is exciting because of its implications on a broader level... i do buy the "Excitingly boring" compliment bit but anything new isn't necessarily exciting and old stuff isn't always boring.
I think Exciting Technology, especially in the programming world, is mostly built on top of existing technology, and for me personally, I choose Boring Technology for doing that.
True, but if your app is running Rust on Postgres, then that might well be a win over C++ on OracleDB.
For me a key thing is that "boring" doesn't just mean mature and well established. C++ is mature and well established but it's not boring because there are all sorts of nasty memory safety issues to keep things "exciting". OracleDB is mature and well established, but from what I hear you have to pay expensive fees to do all sorts of things: that's not boring!
Point taken, but Nim is pretty stable in my (somewhat limited) experience with it. Though the original article does mention innovation tokens, which in this case would be exceeded.
You can't just choose technologies, especially frameworks, the way you would choose tools. Tools simply shape the result of your work — it doesn't matter what you used to make something, as long as it turned out good. Frameworks and libraries stay inside your product, and directly affect how your users experience it.
Choosing exciting can be a tech-debt, or it can remove tech debt. Boring can be stable, but can be soul-crushing.
Exciting & Boring is not mutually exclusive. They can co-exist. Engineer excitement and Business continuation must be kept in balance.
Generalization is not helpful. As an engineer or business, or in general a sensible person, you must always do pros and cons without bias.
Thanks for comimng to my TED Talk.