101–110 of 356 posts
https://mcfunley.com/choose-boring-technology
I think one big part of the mistake is using Hacker News, Reddit, conferences as a sign of what companies are actually using. Instead, I liken it to a bazaar:
https://www.nemil.com/on-software-engineering/beware-enginee...
Oh, and remember marketing is not reality, even though marketers try awfully hard:
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…
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?
Such strongly opinionated statements should be taken with caution. In our profession context is key and this theory does not always apply in every context. Imagine if the Netflix guys were told to stay boring and not invent new shiny things? Ofcourse not everyone is in that scale. I do not want to use the latest shiny tech but I do not want it to be boring as well. We are confusing KISS and boring here. A company I u…
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. Great that he's spreading the word!
Code is not "a liability". It is a tool that can be used masterfully or utterly abused. Every craftsman has to invest in their tools. And for someone to truly master their craft they must sometimes hone their tool skills speculatively, without short-term gain, and by sacrificing the time and attention used for other things, like actual projects. If everyone just obeyed their project manager and always focused 100% on…
What was missing in the gp comment is that code is also an asset. The goal is to have the value of the asset greater than the liability. This ratio changes over time given a multitude of factors like problem domain and how well the original code was written.
Earlier quoted context omitted.
In the real world with limited resources, limited skills, limited budgets and limited brain power, yes code is a liability. Not only a liability, but a liability among other things.
>In the real world with limited resources, limited skills, limited budgets and limited brain power, yes code is a liability. That's an unbalanced conclusion. Code can be a liability but it can also be an asset . Do we have limited resources? Maybe writing new code can help. E.g. In cars, the electronic fuel injectors have computer code determining the optimal amount of gas to inject to minimize fuel usage. Fuel effic…
That's where those aphorisms come from. No code runs faster than no code! No code has fewer bugs than no code! No code is easier to understand than no code!
Such strongly opinionated statements should be taken with caution. In our profession context is key and this theory does not always apply in every context. Imagine if the Netflix guys were told to stay boring and not invent new shiny things? Ofcourse not everyone is in that scale. I do not want to use the latest shiny tech but I do not want it to be boring as well. We are confusing KISS and boring here. A company I u…
One thing is to "use boring technology" and a different thing is to "build boring products"... I can build shiny new things with boring technology.
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.
Such strongly opinionated statements should be taken with caution. In our profession context is key and this theory does not always apply in every context. Imagine if the Netflix guys were told to stay boring and not invent new shiny things? Ofcourse not everyone is in that scale. I do not want to use the latest shiny tech but I do not want it to be boring as well. We are confusing KISS and boring here. A company I u…
While I see the point, I also see that all "boring" technologies were new kids on the block at some moment, and often succeded at replacing previous "boring" thing. So maybe the proper advice should sound less absolute. Something like: Be cautious, and don't discard less exciting technologies, just because they are older.