15 ms·

I've been working in the tech industry in the US for about 5 years. Ever since I knew myself I've been coding. From middle school to high school, given any prob

I've been working in the tech industry in the US for about 5 years. Ever since I knew myself I've been coding. From middle school to high school, given any problem, like Sudoku, or keeping up daily chores, my solution was Programming! Programming wasy homebase. Then I studied it in uni, thought I was kinda good at it, and loved it. But when I started working in the industry, I realized that it's absolutely exhausting. Hype after hype, fad after fad, modern after modern, refactor after refactor. I have a workflow, I know how to build apps. Then one day director of Ops comes and completely and utterly changes the workflow. Ok fine, I'm young, will learn this. Month passes, it is now Terraform. Ok fine I'm young, will learn this. Now we're serverless. Ok fine, will learn. Now everything is container. Ok. Now everything microservice. K. Now turns out lambdas aren't good, so everything is ECS. OK will rewrite everything... Look I'm not even complaining. But it feels like I'm stuck in a Franz Kafka novel. We just keep changing and changing the same things again and again because that's the new way to do. Big distraction. Destroys your workflow. Forget about all the util scripts you wrote last 6 months being useless. I don't even know how I would do it. Maybe I would do this the same way if I had any power. But that doesn't change the fact that it's a bit ridiculous. Fun but tiring. Entertaining but exhausting. Cute but frustrating.

deleted 3y ago
[deleted]
lastyearmodel 3y ago
Completely anecdotally, but the most productive I've ever been in a company has been was a company in 2016-2019 who was on a monolith .ENT Framework with no kube/container setup at all. Sure, it felt like absolute chaos some days, but I"ve never felt more productive and in a flow as then, mainly because we weren't chasing the latest and greatest thing but focusing on what's working for us and perfecting it.
- rqtwteye 3y ago
  The sad thing is that in many cases working on such a system is a career killer. Nobody wants to hire you. Some years ago a colleague and I realized that our company wouldn’t hire us judging from the job descriptions because we worked on systems that had been working for years but weren’t shiny. Since then I always something new to every project. Not because it makes sense but because it’s good for the resume. Other groups are even worse. Three devs writing 13 micro services on Kubernetes for maybe a thousand users ever.
  - noduerme 3y ago
    After 20+ years of maintaining what amount to monoliths and services, I wonder whether I'd be hirable if I had to find a job at some big tech company. But I think the problem-solving ability you need to manage server clusters you built yourself translates into the ability to handle whatever their cloud junk looks like. Hopefully I'm never in that position, though, because I would absolutely hate a job like that.
  - deaddodo 3y ago
    It's not a career killer, it's a specialization. Focusing on nodeJS JS/TS frontend+backend stacks will equally disqualify you from .NET/Spring shops (against an equally qualified applicant, at least). The same goes for making the switch to gamedev or systems dev from many years webdev (you can do it, but you'll probably be dropping back down to a Jr or Mid-level IC position), going from COBOL/Erlang/Rust to another stack, doing Salesforce (or other CRM/specialty software) development, etc. It's going to happen to anyone after 10-15years in the industry.
    - laeri 3y ago
      You are right that this is specialization but it still is a career killer in the case that you specialize on a completely obscure technology which will not help in your future career.
  - plorkyeran 3y ago
    I think this fear is not entirely wrong, but is significantly overblown. There's a significant gap between what job descriptions ask for and what companies will actually hire. A resume full of dead technology isn't going to help you ladder your way up to bigger and higher-paying roles, but it's also not going to make you unemployable. A resume full of less-shiny but still relevant technologies, otoh, has a lot of potential. You have fewer places to look for jobs, but you're a lot more exciting to the places which do want your skills.
    - eschneider 3y ago
      When I look for a new position, I try and make sure it’ll allow me to learn a new fundamental skill rather than the latest new framework (though often there’s overlap:) Over 30 years that’s allowed me to be employable across a lot of different tech stacks.
hardwaresofton 3y ago
> Look I'm not even complaining. But it feels like I'm stuck in a Franz Kafka novel. We just keep changing and changing the same things again and again because that's the new way to do. Big distraction. Destroys your workflow. Forget about all the util scripts you wrote last 6 months being useless. Here's how I stay sane -- I focus on the changes. For the technologies that you noted, here are some good questions that come to mind to set them in my brain: - What's the difference between CGI scripts and Serverless? - What's the difference between Terraform and Ansible? - What's the difference between a Bash script and a Makefile ? Is one more general than the other? Does one have a considerably better interface than the other? All the solutions look the same, but the distinctions between them (even at a relatively surface level) are what help to actually tell things apart and stop the feeling of endless churn. I think of it this way -- unlike other fields because the fruits of our research are immediately usable and almost zero-cost, we're given a front seat to the frontier of experimentation. It's a water hose, and you have to determine which streams are worth turning on/off, bottling for later.
- noduerme 3y ago
  I have this impulse to constantly experiment with everything too. And I think it's healthy for your brain to always be learning new ways and testing your preconceived notions of how you do things. A lot of times it leads to incremental advances, either in the next iteration of my existing code or the way I approach my next project. But a lot of it, I can admit, boils down to sheep shaving. When you start figuring out how you'd implement codebase 2009 in stack 2023, and then actually doing it, that's golf. It's all good, it's educational, but it's downright immoral to sell that to a client and drag them through it.
  - hardwaresofton 3y ago
    > But a lot of it, I can admit, boils down to sheep shaving. AKA Yak shaving[0], which I am... unashamedly fond of doing >> There are yaks to shave all over the stack, and I go where the yaks are. (quote is from my github readme) > When you start figuring out how you'd implement codebase 2009 in stack 2023, and then actually doing it, that's golf. It's all good, it's educational, but it's downright immoral to sell that to a client and drag them through it. I definitely agree that selling this to a client when you've told them you'll do the minimum to update the codebase is immoral, but if there is value in updating, then you should expose them that value. For example -- moving a client to AWS might not make sense, but if they're maintaining on-prem infra and paying tons of money for an application that would actually cost less as a single ECS service (or App Runner, these days)... Then maybe you should upgrade their stack a little bit. In the end it's your job as a consultant or an employee (if you're high level enough) to introduce change that will make the company better, if you see an opportunity. Tech stacks crumble underneath their own weight, and if they're bad enough, become business risks. If it's humming along, easy to maintain, and isn't riddled with security holes, then great! [0]: https://en.wikipedia.org/wiki/Yak_shaving https://en.wikipedia.org/wiki/Yak_shaving
noduerme 3y ago
I've watched this happen to so many coders in the land where people write code for companies that sell code. Personal advice: Write code for any other kind of company. They're much more resistant to fads. They don't care how you accomplish the new feature. They just want to get it done. And they certainly don't want to change their stack, ever, although in a new project you'll have more flexibility to pick the right tools than you would in a software company that's obsessed with the newest thing.
- deaddodo 3y ago
  Having worked at both, the latter type of company also has it's downsides. Primarily: a) the inverse is also true...you'll be working on some old technology that only your industry utilizes and isn't well optimized for modern use cases or is extremely niche; despite there being plentiful use cases to make the switch, it'll never be "in the budget", b) your payrate is generally going to be quite a bit lower than industry standards at app/tech companies and c) you won't get the same treatment as an engineering focused company. The latter two are very much variable by company, but those are the general trends. They'll also vary in importance to different people. The former item, however, can be just as burn-out/tedium prone as tech company stack whiplash.
  - noduerme 3y ago
    Maintaining old systems and not getting the chance to exercise your hottest take on how they should be rebuilt is often tedious as hell. But I find a lot of comfort in it. I usually find that the future road maps that stick in my head for a year or more are the ones worth a 10-year overhaul, and I like to be able to tell clients that when enough of their stack is reaching end of life, we should do this major rewrite but I already am fairly certain they won't have to do it again for another 10 years. e.g. I have yet to deploy any production code for a client running on Nodejs, but I've written enough dependable systems in it on my own free time in the last 5 years that I think I might now finally advocate for it under certain circumstances, knowing the strengths and weaknesses. It does help - as you point out - to be in the position where the non-tech company will almost always take your advice if you tell them they need to change platforms. But the most effective way of getting yourself in that position is to prove that you exercise that option only when it truly is in their best interests.
bruce511 3y ago
>>when I started working in the industry, I realized that it's absolutely exhausting. It's been this way forever. For every level of the stack. When I started the physical hardware hadn't been settled (coax, ethernet, token ring etc.) Fortunately when I started we only got paid when we shipped. So we were motivated to ship, not be distracted by rewrites. We were also lucky that as a boot-strapped company we had no managers calling the shots. We made decisions and stuck to them, and it's paid off over the long run. Of course the product has changed immensely over 25 years - but the core code laid down in 1996 is still integral. We've spent the time on the product, not worrying about the sexiness of the tech stack. Which is not to say we've ignored the tech stack, it's evolved a lot, but the stack serves the product, not the other way around. On the other hand we don't have to raise investments, we don't have to attract endless streams of new programmers, we don't have to juice a stock price, so we don't have to appear modern or hip. We can just keep doing what we do, making money, focusing on the value to customers, not being (easily) distracted by the next shiny toy. And yeah, after a couple decades you learn to see through the hype a bit and distinguish things that are good for you, not just the flavor of the week.
- another2another 3y ago
  >(coax, ethernet, token ring etc.) Well, some things did bring improvements, or new ways of thinking about existing problems, and some things really moved the state of the art. Taking your example of token ring -> coax (with terminators,eek!) -> ethernet is arguably a good progression (and now also wifi). But there's also lots of churn in software and people solving the same problems in slightly different ways. However ... this is also collateral damage from another improvement, imho - that is the ceding of control of the tech landscape from big companies (IBM, Oracle, Microsoft, Intel, Sun, Borland) to smaller open source clusters of people and VC funding. There was a time when nothing happened without some big tech company behind it, and everybody waited for (particularly MS) to bless things and provide library support, IDEs and tools. Those days are over, but the result is a bazaar of nosql servers, messaging servers, languages and front-end JS frameworks.
seanp2k2 3y ago
Stuff like this is why the notion that AI will eat all the software jobs in a few years is so ridiculous to me: who will maintain all the infra? Maybe AI will very eventually, but there's still a whole lot that needs to happen for the AI magic to magic, and it's not like VPs are going to be able to write implementable specs in enough detail for an AI SWE to implement them, wire them into the right branch / tag / whatever in the release system, communicate with stakeholders to plan a deployment, do the release, monitor for bugs / regressions, patch as necessary and port those into the dev branch, etc etc. There's a whole lot more to modern SWE roles than just staring at an IDE with the job "implement a function that given X returns the square of X" type stuff that current AI can implement well.
sublinear 3y ago
> it's absolutely exhausting I'm not young, yet I don't find any of this all that bad. Maybe I'm an outlier, but I see refactoring and learning new tools as just keeping the blade sharp. Migrating to new frameworks, tools, etc. is just superficially iterative. I've yet to see some kind of massive paradigm shift blow me away and stress me out.
- fodkodrasz 3y ago
  I wanted to share my ideas, but it just turned into a rambling: The problem is not with massive paradigm shifts... actually we are yet to see something like that. The constant busywork on industrial scale is what the problem is, the constant reinvention of the wheel in a way that is somewhat still incompatible yet the same thing. Most change is only for the sake of change, for NIH-syndrome. when a solution for a problem gets half-decent, and almost as good as it was in the windows 2000 times, then it gets forked/dumped and a new half as good fad appears... There is no problem with learning new tools, but learning a new UI framework every 2 years just to be constantly half-as capable as Delphi was (okay, with rounded corners and animations, I give you that) can be really tiresome. Cloud vendors changing their line-up constantly so that your certifications expire, and they can remove the really good value for the buck services and push the shiny new globally replicated and 10x more expensive new stuff (which delivers value for many, but the barebones stuff also did for many others). Just my 0.02$, probably saw too many lets rewrite in $current-thing and don't use $industry-standard-battle-tested-thing, as it is hard to learn it, but let's write one from scratch! (last time a team in a job decided that configuring HAProxy (my suggestion to get stuff done cheaply and quickly) is too hard, it is better to write a high performance reverse proxy, because it will be our thing! (I guess they were more interested in their resumes than in the company's interests). Since then that company is bankrupt... who would've thought)
- einpoklum 3y ago
  > as just keeping the blade sharp Replacing weapons and keeping blades sharp is not the same thing. Now, the metaphor kind of breaks down because new weapons are sharp, but abilities with a new technology are typically not, i.e. you use new tech as somewhat of a blunt instrument until you learn the finer points of it - and until it develops and matures enough itself. So, if you want to use "sharp blades" - don't switch technologies, but rather keep with the updates to those you already know.
tsguy 3y ago
I checked terraform and lambda stuff in 2016 and then decided to continue with ECS bcz as an entrepreneur i find it to wonderful and time and money saving you know. Easy to deploy and also you can utilise cheap spot instances to fullest.
mcv 3y ago
Yeah, you can't jump on every hype. I started in web dev almost 20 years ago (did some Visual C++ before that). First job was everything XML. We had our open source CMS that stored all documents as XML and used XSLT to transform it into the HTML we needed. Was pretty cool, but there's always something that didn't fit that paradigm. Some coworkers went a bit overboard and used XSLT to generate the XSLT to create the HTML. But it all works as long as you cache aggressively. Second was Ruby on Rails with JQuery. And eye-opener for me. Very cool to work with. Third job was similar, but using Groovy instead of Ruby. After that, I ended up in SPA-land: first Angular, then Vue, now React. Backends in either Java or Node.js. I'm still doing that, only now everything needs to be in Docker and Kubernetes. I still don't know why I should ever need microservices. Our GraphQL. We actually considered GraphQL for previous project, and decided not to because it looked way too complicated. It sounds like it might fit with using a Graph DB (I'm a big fan of neo4j), but it doesn't. At my current project, they made that decision before I joined, and they've since realised that they don't need GraphQL after all, but it's in there now, so they just work around it. Some of the hypes worked very well for me (XML, jQuery, Ajax, SPA), others seem to work well for others but not me (docker, kubernetes), and some I really don't see the point in (microservices, GraphQL), but I assume there are use cases where they shine. But don't blindly adopt everything. First check if it actually fills a need you have. And how it will fill that need.
- Blaiz0r 3y ago
  Microservices are more an organisational thing than a recommended pattern, when a project grows and wants to hire more staff to increase its bandwidth then microservices are a great way to support that, the additional benefit is that they work great in a CI/CD setup so you can release seamlessly. GraphQL from what I can tell supports web developers rewriting their APIs when they need to instead of waiting on back-end teams to support them.
  - mcv 3y ago
    Most of my projects have just a single team in charge of a single code base, so there seems to be no need for microservices at all, and yet some people keep bringing up that we should really look into microservices. My impression is that GraphQL is great if you're building an api that's going to be used by lots of different teams with different needs and the api developer doesn't know what they are. Again, with a single team doing everything, there's no need for it at all. But we're using it anyway. Also, they keep talking about a Single SPA Application, and I can't tell if that's just a redundant way to say SPA, or if it's really something new, or if they're just messing with me.
CJefferson 3y ago
I'm constantly sad there isn't any good writing on this topic. Does anyone have any suggestions on anything to help me keep up with the basics of new fads? I would love a monthly (doesn't have to be exactly monthly, but the point is occasional) magazine, which was the equivalent of those old magazine with basic tutorials, which would give overviews, and comparisions, of all the various modern techs floating around. I do occasionally find a new person's blog to subscribe to, but I've never found a good general source.
makeitdouble 3y ago
To give another perspective, at my first job deploying meant sshing into production and execute a make script. It worked 98% of the time, and you'd be having fun the 2% else. It sure wasn't the state of the art, but wasn't something people would yell at you for. We needed windows machine because of corporate policy and remoted into a Solaris box to dev, as a vague replica of production. Fast forward to today, and we can run a production replica on our local machines at home, the CPU architectures aren't even the same, and code will be deployed through the CI automatically after the tests all pass. Sure not all changes are meaningful, but in the grand scheme of things the field is moving forward in spades. I certainly wouldn't want to go back a few decades.
- coldtea 3y ago
  >Fast forward to today, and we can run a production replica on our local machines at home, the CPU architectures aren't even the same, and code will be deployed through the CI automatically after the tests all pass. And someone we squandered most of the CPU performance increases in the process, and the super-duper architecture/CI/delivery pipeline fails almost the same percentage of the time, but needs 10x the people to keep it running...
  - makeitdouble 3y ago
    CI and delivery failing 2% of the time just means you haven't deployed and you just retry. At least you're not poking things in prod. I'm with you on the CPU gains going down the drain and 10x more people working on it, but it's also a sign that we're talking IT operations more seriously and there's enough money to cover these kind of inefficiencies.
- shocks 3y ago
  Here’s another perspective: A decade ago you could deploy an internal PHP app to a box and forget about it for a few years, then fix a minor bug by sshing in, viming a file, and hacking it a few times. These days, if you leave the app untouched for six months that 10 minute fix becomes 2 hours of fixing a broken docker build. :)
sakopov 3y ago
Around the time Angular came out with v2 and everyone basically realized that they either had to completely rewrite their Angular apps or spend the same effort to migrate to React (which was the new hotness at the time) I really started contemplating whether it's possible to stay sane while keeping up with the pace of change in both back-end and front-end paradigms. I ended up switching from full-stack to back-end dev. I don't know if it's just me, but now it seems like things have started to calm down and we're just iterating on existing problem sets and frameworks rather than throwing everything out and starting over. Does anybody feel the same? I actually think this is the best time to dive back into full stack dev.
boffinAudio 3y ago
Use what works. Ship code. Support your customers. Help them improve their lives. All other considerations are secondary. Including whether or not your peers approve of your code. Always remember: the User is king. Programmers are nothing without users, no matter what technology they apply to the situation. Sounds like you've shipped, and shipped often. GOOD!
- flir 3y ago
  But there are so many layers of abstraction between me and my user... (human layers, not software layers)
  - boffinAudio 3y ago
    All the more reason for you to keep the user in mind while you wade through the crud.
  - andruby 3y ago
    Do you think there are too many layers in between? Can you help reduce the number of layers?
JBiserkov 3y ago
> But it feels like I'm stuck in a Franz Kafka novel. Director of O(o)ps: Funny that you should mention that...
- JBiserkov 3y ago
  https://kafka.apache.org/ https://kafka.apache.org/
  - TeMPOraL 3y ago
    Franz Kafka meets the Wild West.
agumonkey 3y ago
somewhere, deep in an archive room, a cobol developer is smiling
einpoklum 3y ago
This is a benefit (non-commercial) FOSS has over software authoring in commercial corporations. Developers get to call the shots, and usually, don't bend to such passing fads. > I don't even know how I would do it. Depends on the software you're writing of course, but the core would probably be some libraries with C (and maybe other language) bindings, some command-line executables, and anything else - above that.
andruby 3y ago
I can imagine this is frustrating and have experienced people wanting to push the "latest trend". My usual way to approach this is to ask them to explain to me the _why_. Why is this new thing better? What specifically is it better at? How? What trade-offs does it make? More often than not, they aren't able to properly articulate the why and the trade-offs involved. Sometimes they do fully understand the trade-offs and that leads to good discussions.
samsquire 3y ago
Thanks for your comment, I enjoyed it. I think the computer industry is in its infancy and we haven't really found the right solution to many problems, for everyone to adopt the same thing requires it to be a very good option. BSD sockets is used by everyone - it's that good. It reminds me of xkcd #927 about standards ( https://xkcd.com/927/ https://xkcd.com/927/ ) I would like a solution to the problem where library code is changed and it breaks code that relies upon it. I would also like an API description format that we can code against and doesn't break.
AdamCraven 3y ago
It's because a lot of engineers are learning to become better plumbers, not better engineers. Trying new technologies means you're mostly becoming better at using someone else's APIs - this is the path to eventual burn out as the churn continues. There is a better path - See through the hype. Ask those around you what's the downsides to this approach? And you'll often get blank stares... Why? Because they don't know either - And if they don't know the downsides, they don't really know. They are following the hype curve. Focus on the fundamental engineering principles and asking better questions - take the bottom-up approach and the reward is you'll find teams that aren't taken by the hype curve so easily. PS. There are a lot of good technologies that come out, but staying behind the hype curve a little helps you make better judgements over time.
nigma1337 3y ago
I have such a fear for this, that things i invest time/energy into today will be obsolete in half a year, and my time would be essentially "wasted". As others say, learning the fundamentals will, and trying to get some more general skill out of every tech fad. (although, full rewrite every 6 months is excessive imo)
wofo 3y ago
Wow, this resonates with me! I stopped doing full-stack development a while ago, and have since January been contributing to open source projects as a contractor (my next gig will be for ISRG, the makers of Let's Encrypt, :D). By working on open source libraries I get to tackle interesting problems without being bogged down too much by accidental complexity. It feels like the ideal solution to me (though it is difficult to replicate, as it takes quite some luck).
DarkCrusader2 3y ago
I am in the exact opposite,but equally frustrating boat. In last 5 years, I have worked at 2 Faang and a large hedge fund and everywhere they had extremely outdated stack or undocumented in-house stack or outdated undocumented in-house stack. Already derecated dependencies were pinned years ago and management won't let you modernize anything since there "no business value in it" and we need to ship a feature instead and if you still insist to refactor and modernize and something goes wrong, now you are personally responsible for the outage. The effort you spent successfully upgrading decades old stack won't count in your promo packet. There is just no incentive to upgrade anything beyond security fixes. Rewrite to chase the latest fad is frustrating but using technologies which don't even have online documentation anymore is equally if not more frustrating.
- Quarrelsome 3y ago
  I was stuck maintaining a solution using an abandonware internal transport layer built on technology that died in 2004 and an abandoned ORM on an EAV schema database over SOAP backend in 2022 with much the same "no business value in it" argument. "We're trying to sell the company so profit is of the most importance" transitioned into "we bought you because you make money". So instead we increased our maintenance exposure by adding more necessary features to the wobbly pile (or 'fixing' broken ones) as opposed to resolving the mistakes made over twenty years ago. Of course the dickhead architect would use articles like this OP as justification for why all of this wasn't a problem.
- mathgeek 3y ago
  Today’s beloved tech with well maintained docs is tomorrow’s institutional knowledge tech that companies rely on.
  - pdimitar 3y ago
    Not my observation sadly. We've got some excellent 10+ years old tech -- Golang, Rust, Elixir -- yet a lot of companies out there holds on to C#, PHP and Java with an death grip. And I've worked with all of these. The newer stuff is better in every way except penetration (which is held back by bias and misguided evaluations of the word "safe").
Waterluvian 3y ago
After a decade I think I’ve concluded for myself that this is, for the most part, a self-inflicted problem. There’s really no need to keep refactoring or feel like others need to stop inventing new ways of doing things.
lumb63 3y ago
Have you ever considered a different portion of the tech sector? I work in embedded systems and this couldn’t be further from the truth. Things rarely change (because it took someone smart banging their head against a wall for a week to make it work) and if they do, they’re usually addressing real needs in the systems programming community. I see each change less as a fad and more as an additional tool in the tool belt. Take for example Rust, which is gaining traction in parts of systems programming. It addresses the direct need to stop overflowing buffers, create more strong typing, write less code to accomplish the same thing, and others. Accordingly, a lot of systems programmers are optimistic and excited about it. But everyone in the field knows C, and acknowledges C isn’t going anywhere. There are tasks for which C is better suited right now, and will be for a very long time. There’s no push to rewrite all programs in Rust. Sure, some are pushing for it, but it’s not a “this year is Rust, next year is <new programming language>” dynamic. It’s a “this is where we want to go, but it’s going to take us many years to get there” type shift.
otabdeveloper4 3y ago
Be thankful there are still people willing to pay you for bullshit jobs. Things will be tougher when management starts asking for real, measurable results.
- ed25519FUUU 3y ago
  Gotta make hay while the sun is shining.
- BeFlatXIII 3y ago
  Perhaps that would be the time to transition into playing rainmaker.
commandlinefan 3y ago
> Hype after hype, fad after fad, modern after modern, refactor after refactor And you're supposed to already know how to do it and give an accurate ~~estimate~~ prediction for how long it's going to take to do (that matches the amount of time they've already decided you have to do it). You're a _professional_ and professionals don't need time to actually learn how to do something new, they just know.
exhuma 3y ago
I've been in the industry for over 30 years and I absolutely get where you're coming from. It is an ever changing field and it can be exhausting. I hear this repeatedly from many coworkers (and workers from the same field). All I can give is some advice from my lengthy experience. Most of the changes happen on the "edges". Those edges are primarily three fold: First, the user interface: everything that deals with input parsing and formatting. This also includes protocol marshalling (Http, JSON, XML, ...) Second the data persistence. This involves choice of database or any other persistence. Including serialisation of your data. Any I/O really. Third, anything to do with deployment. This includes environment isolation, configuration management, process automation and so on. These the edges have nothing to do with your core application logic. You can reduce the impact of a switch to a new stack by inflating your core logic and shielding it from the rest of your stack. This is tricky and I still catch myself all the time doing it wrong. Because doing it wrong is tempting and easy. For example, consider a connection to the db: you will need a connection string. You can fetch that from an environment variable somewhere deep in your core code. But by reaching out to the system like that, you make that core piece of code dependent on the deployment strategy. Instead, you can move that part as close as possible to the entry point and then pass it down as function/class arguments. You can group similar operations together, close to the entry point. That way, if the dependent e strategy or the stack changes, your core code does not need to change. Another example is the case where your core code is dependent on a library from your stack. For example, when working with python and flask, it's easy to import "request" or "g" from the framework. But every piece of code relying on that will be tightly coupled to the framework and subject to change whenever the framework changes (either same framework with breaking changes, or framework switch). The solution is the same. Move those elements as close as possible to the entry points. In this example of flask, keep this as close as possible to your routes. But also keep your routes clean of core logic. Interact with the HTTP layer only and pass the values as arguments to your core. Finally, a similar situation, but much more sneaky and hard to spot is reliance on data types from your stack. Spotting cases where you rely too much on library modules can be done by investigating imports. But reliance on data types is harder to spot. Sticking with the flask example: the http headers are encapsulated by an object of the flask stack (werkzeug in this case). You may be careful and extract the headers in the route to follow my earlier example. But if you then pass the headers unmodified down into your core logic you will again be coupled to the stack. Instead you should extract only the values you care about and hand only those down to break the coupling. Finding the right balance where to cut the coupling is challenging. The more you cut, the better you will be shielded from changes. But the less you can benefit from pre existing implementations from the stack. Where to cut is ultimately a design decision. When done well, it will be far less frustrating to jump on the bandwagon of the latest tech. Not completely painless but far less stressful. Not least because you will have confidence that you didn't accidentally break core logic.
Hermitian909 3y ago
I have a partial solution to this I'm happy pretty happy with. First, is that I dove farther into CS fundamentals. This has made new fads a lot easier to deal with because usually they're recycling old CS ideas. React hooks is a good example. I wrote class components for many years, adopting to hooks took me all of a day because Algebraic effects were something I understood well. Second - I am firm about which tech I do and do not want to learn the specifics of. I understand the high level of kubernetes but will not be learning specifics.
red-iron-pine 3y ago
> We just keep changing and changing the same things again and again because that's the new way to do Capitalism doesn't work unless you have something to sell, and that's just as true for tech as it is anywhere else.
cyanydeez 3y ago
My man's ear never heard of corporate growth culture

deleted 3y ago

[deleted]

lastyearmodel 3y ago

Completely anecdotally, but the most productive I've ever been in a company has been was a company in 2016-2019 who was on a monolith .ENT Framework with no kube/container setup at all. Sure, it felt like absolute chaos some days, but I"ve never felt more productive and in a flow as then, mainly because we weren't chasing the latest and greatest thing but focusing on what's working for us and perfecting it.

rqtwteye 3y ago
The sad thing is that in many cases working on such a system is a career killer. Nobody wants to hire you. Some years ago a colleague and I realized that our company wouldn’t hire us judging from the job descriptions because we worked on systems that had been working for years but weren’t shiny. Since then I always something new to every project. Not because it makes sense but because it’s good for the resume. Other groups are even worse. Three devs writing 13 micro services on Kubernetes for maybe a thousand users ever.
- noduerme 3y ago
  After 20+ years of maintaining what amount to monoliths and services, I wonder whether I'd be hirable if I had to find a job at some big tech company. But I think the problem-solving ability you need to manage server clusters you built yourself translates into the ability to handle whatever their cloud junk looks like. Hopefully I'm never in that position, though, because I would absolutely hate a job like that.
- deaddodo 3y ago
  It's not a career killer, it's a specialization. Focusing on nodeJS JS/TS frontend+backend stacks will equally disqualify you from .NET/Spring shops (against an equally qualified applicant, at least). The same goes for making the switch to gamedev or systems dev from many years webdev (you can do it, but you'll probably be dropping back down to a Jr or Mid-level IC position), going from COBOL/Erlang/Rust to another stack, doing Salesforce (or other CRM/specialty software) development, etc. It's going to happen to anyone after 10-15years in the industry.
  - laeri 3y ago
    You are right that this is specialization but it still is a career killer in the case that you specialize on a completely obscure technology which will not help in your future career.
- plorkyeran 3y ago
  I think this fear is not entirely wrong, but is significantly overblown. There's a significant gap between what job descriptions ask for and what companies will actually hire. A resume full of dead technology isn't going to help you ladder your way up to bigger and higher-paying roles, but it's also not going to make you unemployable. A resume full of less-shiny but still relevant technologies, otoh, has a lot of potential. You have fewer places to look for jobs, but you're a lot more exciting to the places which do want your skills.
  - eschneider 3y ago
    When I look for a new position, I try and make sure it’ll allow me to learn a new fundamental skill rather than the latest new framework (though often there’s overlap:) Over 30 years that’s allowed me to be employable across a lot of different tech stacks.

hardwaresofton 3y ago

> Look I'm not even complaining. But it feels like I'm stuck in a Franz Kafka novel. We just keep changing and changing the same things again and again because that's the new way to do. Big distraction. Destroys your workflow. Forget about all the util scripts you wrote last 6 months being useless. Here's how I stay sane -- I focus on the changes. For the technologies that you noted, here are some good questions that come to mind to set them in my brain: - What's the difference between CGI scripts and Serverless? - What's the difference between Terraform and Ansible? - What's the difference between a Bash script and a Makefile ? Is one more general than the other? Does one have a considerably better interface than the other? All the solutions look the same, but the distinctions between them (even at a relatively surface level) are what help to actually tell things apart and stop the feeling of endless churn. I think of it this way -- unlike other fields because the fruits of our research are immediately usable and almost zero-cost, we're given a front seat to the frontier of experimentation. It's a water hose, and you have to determine which streams are worth turning on/off, bottling for later.

noduerme 3y ago
I have this impulse to constantly experiment with everything too. And I think it's healthy for your brain to always be learning new ways and testing your preconceived notions of how you do things. A lot of times it leads to incremental advances, either in the next iteration of my existing code or the way I approach my next project. But a lot of it, I can admit, boils down to sheep shaving. When you start figuring out how you'd implement codebase 2009 in stack 2023, and then actually doing it, that's golf. It's all good, it's educational, but it's downright immoral to sell that to a client and drag them through it.
- hardwaresofton 3y ago
  > But a lot of it, I can admit, boils down to sheep shaving. AKA Yak shaving[0], which I am... unashamedly fond of doing >> There are yaks to shave all over the stack, and I go where the yaks are. (quote is from my github readme) > When you start figuring out how you'd implement codebase 2009 in stack 2023, and then actually doing it, that's golf. It's all good, it's educational, but it's downright immoral to sell that to a client and drag them through it. I definitely agree that selling this to a client when you've told them you'll do the minimum to update the codebase is immoral, but if there is value in updating, then you should expose them that value. For example -- moving a client to AWS might not make sense, but if they're maintaining on-prem infra and paying tons of money for an application that would actually cost less as a single ECS service (or App Runner, these days)... Then maybe you should upgrade their stack a little bit. In the end it's your job as a consultant or an employee (if you're high level enough) to introduce change that will make the company better, if you see an opportunity. Tech stacks crumble underneath their own weight, and if they're bad enough, become business risks. If it's humming along, easy to maintain, and isn't riddled with security holes, then great! [0]: https://en.wikipedia.org/wiki/Yak_shaving https://en.wikipedia.org/wiki/Yak_shaving

noduerme 3y ago

I've watched this happen to so many coders in the land where people write code for companies that sell code. Personal advice: Write code for any other kind of company. They're much more resistant to fads. They don't care how you accomplish the new feature. They just want to get it done. And they certainly don't want to change their stack, ever, although in a new project you'll have more flexibility to pick the right tools than you would in a software company that's obsessed with the newest thing.

deaddodo 3y ago
Having worked at both, the latter type of company also has it's downsides. Primarily: a) the inverse is also true...you'll be working on some old technology that only your industry utilizes and isn't well optimized for modern use cases or is extremely niche; despite there being plentiful use cases to make the switch, it'll never be "in the budget", b) your payrate is generally going to be quite a bit lower than industry standards at app/tech companies and c) you won't get the same treatment as an engineering focused company. The latter two are very much variable by company, but those are the general trends. They'll also vary in importance to different people. The former item, however, can be just as burn-out/tedium prone as tech company stack whiplash.
- noduerme 3y ago
  Maintaining old systems and not getting the chance to exercise your hottest take on how they should be rebuilt is often tedious as hell. But I find a lot of comfort in it. I usually find that the future road maps that stick in my head for a year or more are the ones worth a 10-year overhaul, and I like to be able to tell clients that when enough of their stack is reaching end of life, we should do this major rewrite but I already am fairly certain they won't have to do it again for another 10 years. e.g. I have yet to deploy any production code for a client running on Nodejs, but I've written enough dependable systems in it on my own free time in the last 5 years that I think I might now finally advocate for it under certain circumstances, knowing the strengths and weaknesses. It does help - as you point out - to be in the position where the non-tech company will almost always take your advice if you tell them they need to change platforms. But the most effective way of getting yourself in that position is to prove that you exercise that option only when it truly is in their best interests.

bruce511 3y ago

>>when I started working in the industry, I realized that it's absolutely exhausting. It's been this way forever. For every level of the stack. When I started the physical hardware hadn't been settled (coax, ethernet, token ring etc.) Fortunately when I started we only got paid when we shipped. So we were motivated to ship, not be distracted by rewrites. We were also lucky that as a boot-strapped company we had no managers calling the shots. We made decisions and stuck to them, and it's paid off over the long run. Of course the product has changed immensely over 25 years - but the core code laid down in 1996 is still integral. We've spent the time on the product, not worrying about the sexiness of the tech stack. Which is not to say we've ignored the tech stack, it's evolved a lot, but the stack serves the product, not the other way around. On the other hand we don't have to raise investments, we don't have to attract endless streams of new programmers, we don't have to juice a stock price, so we don't have to appear modern or hip. We can just keep doing what we do, making money, focusing on the value to customers, not being (easily) distracted by the next shiny toy. And yeah, after a couple decades you learn to see through the hype a bit and distinguish things that are good for you, not just the flavor of the week.

another2another 3y ago
>(coax, ethernet, token ring etc.) Well, some things did bring improvements, or new ways of thinking about existing problems, and some things really moved the state of the art. Taking your example of token ring -> coax (with terminators,eek!) -> ethernet is arguably a good progression (and now also wifi). But there's also lots of churn in software and people solving the same problems in slightly different ways. However ... this is also collateral damage from another improvement, imho - that is the ceding of control of the tech landscape from big companies (IBM, Oracle, Microsoft, Intel, Sun, Borland) to smaller open source clusters of people and VC funding. There was a time when nothing happened without some big tech company behind it, and everybody waited for (particularly MS) to bless things and provide library support, IDEs and tools. Those days are over, but the result is a bazaar of nosql servers, messaging servers, languages and front-end JS frameworks.

seanp2k2 3y ago

Stuff like this is why the notion that AI will eat all the software jobs in a few years is so ridiculous to me: who will maintain all the infra? Maybe AI will very eventually, but there's still a whole lot that needs to happen for the AI magic to magic, and it's not like VPs are going to be able to write implementable specs in enough detail for an AI SWE to implement them, wire them into the right branch / tag / whatever in the release system, communicate with stakeholders to plan a deployment, do the release, monitor for bugs / regressions, patch as necessary and port those into the dev branch, etc etc. There's a whole lot more to modern SWE roles than just staring at an IDE with the job "implement a function that given X returns the square of X" type stuff that current AI can implement well.

sublinear 3y ago

> it's absolutely exhausting I'm not young, yet I don't find any of this all that bad. Maybe I'm an outlier, but I see refactoring and learning new tools as just keeping the blade sharp. Migrating to new frameworks, tools, etc. is just superficially iterative. I've yet to see some kind of massive paradigm shift blow me away and stress me out.

fodkodrasz 3y ago
I wanted to share my ideas, but it just turned into a rambling: The problem is not with massive paradigm shifts... actually we are yet to see something like that. The constant busywork on industrial scale is what the problem is, the constant reinvention of the wheel in a way that is somewhat still incompatible yet the same thing. Most change is only for the sake of change, for NIH-syndrome. when a solution for a problem gets half-decent, and almost as good as it was in the windows 2000 times, then it gets forked/dumped and a new half as good fad appears... There is no problem with learning new tools, but learning a new UI framework every 2 years just to be constantly half-as capable as Delphi was (okay, with rounded corners and animations, I give you that) can be really tiresome. Cloud vendors changing their line-up constantly so that your certifications expire, and they can remove the really good value for the buck services and push the shiny new globally replicated and 10x more expensive new stuff (which delivers value for many, but the barebones stuff also did for many others). Just my 0.02$, probably saw too many lets rewrite in $current-thing and don't use $industry-standard-battle-tested-thing, as it is hard to learn it, but let's write one from scratch! (last time a team in a job decided that configuring HAProxy (my suggestion to get stuff done cheaply and quickly) is too hard, it is better to write a high performance reverse proxy, because it will be our thing! (I guess they were more interested in their resumes than in the company's interests). Since then that company is bankrupt... who would've thought)
einpoklum 3y ago
> as just keeping the blade sharp Replacing weapons and keeping blades sharp is not the same thing. Now, the metaphor kind of breaks down because new weapons are sharp, but abilities with a new technology are typically not, i.e. you use new tech as somewhat of a blunt instrument until you learn the finer points of it - and until it develops and matures enough itself. So, if you want to use "sharp blades" - don't switch technologies, but rather keep with the updates to those you already know.

tsguy 3y ago

I checked terraform and lambda stuff in 2016 and then decided to continue with ECS bcz as an entrepreneur i find it to wonderful and time and money saving you know. Easy to deploy and also you can utilise cheap spot instances to fullest.

mcv 3y ago

Yeah, you can't jump on every hype. I started in web dev almost 20 years ago (did some Visual C++ before that). First job was everything XML. We had our open source CMS that stored all documents as XML and used XSLT to transform it into the HTML we needed. Was pretty cool, but there's always something that didn't fit that paradigm. Some coworkers went a bit overboard and used XSLT to generate the XSLT to create the HTML. But it all works as long as you cache aggressively. Second was Ruby on Rails with JQuery. And eye-opener for me. Very cool to work with. Third job was similar, but using Groovy instead of Ruby. After that, I ended up in SPA-land: first Angular, then Vue, now React. Backends in either Java or Node.js. I'm still doing that, only now everything needs to be in Docker and Kubernetes. I still don't know why I should ever need microservices. Our GraphQL. We actually considered GraphQL for previous project, and decided not to because it looked way too complicated. It sounds like it might fit with using a Graph DB (I'm a big fan of neo4j), but it doesn't. At my current project, they made that decision before I joined, and they've since realised that they don't need GraphQL after all, but it's in there now, so they just work around it. Some of the hypes worked very well for me (XML, jQuery, Ajax, SPA), others seem to work well for others but not me (docker, kubernetes), and some I really don't see the point in (microservices, GraphQL), but I assume there are use cases where they shine. But don't blindly adopt everything. First check if it actually fills a need you have. And how it will fill that need.

Blaiz0r 3y ago
Microservices are more an organisational thing than a recommended pattern, when a project grows and wants to hire more staff to increase its bandwidth then microservices are a great way to support that, the additional benefit is that they work great in a CI/CD setup so you can release seamlessly. GraphQL from what I can tell supports web developers rewriting their APIs when they need to instead of waiting on back-end teams to support them.
- mcv 3y ago
  Most of my projects have just a single team in charge of a single code base, so there seems to be no need for microservices at all, and yet some people keep bringing up that we should really look into microservices. My impression is that GraphQL is great if you're building an api that's going to be used by lots of different teams with different needs and the api developer doesn't know what they are. Again, with a single team doing everything, there's no need for it at all. But we're using it anyway. Also, they keep talking about a Single SPA Application, and I can't tell if that's just a redundant way to say SPA, or if it's really something new, or if they're just messing with me.

CJefferson 3y ago

I'm constantly sad there isn't any good writing on this topic. Does anyone have any suggestions on anything to help me keep up with the basics of new fads? I would love a monthly (doesn't have to be exactly monthly, but the point is occasional) magazine, which was the equivalent of those old magazine with basic tutorials, which would give overviews, and comparisions, of all the various modern techs floating around. I do occasionally find a new person's blog to subscribe to, but I've never found a good general source.

makeitdouble 3y ago

To give another perspective, at my first job deploying meant sshing into production and execute a make script. It worked 98% of the time, and you'd be having fun the 2% else. It sure wasn't the state of the art, but wasn't something people would yell at you for. We needed windows machine because of corporate policy and remoted into a Solaris box to dev, as a vague replica of production. Fast forward to today, and we can run a production replica on our local machines at home, the CPU architectures aren't even the same, and code will be deployed through the CI automatically after the tests all pass. Sure not all changes are meaningful, but in the grand scheme of things the field is moving forward in spades. I certainly wouldn't want to go back a few decades.

coldtea 3y ago
>Fast forward to today, and we can run a production replica on our local machines at home, the CPU architectures aren't even the same, and code will be deployed through the CI automatically after the tests all pass. And someone we squandered most of the CPU performance increases in the process, and the super-duper architecture/CI/delivery pipeline fails almost the same percentage of the time, but needs 10x the people to keep it running...
- makeitdouble 3y ago
  CI and delivery failing 2% of the time just means you haven't deployed and you just retry. At least you're not poking things in prod. I'm with you on the CPU gains going down the drain and 10x more people working on it, but it's also a sign that we're talking IT operations more seriously and there's enough money to cover these kind of inefficiencies.
shocks 3y ago
Here’s another perspective: A decade ago you could deploy an internal PHP app to a box and forget about it for a few years, then fix a minor bug by sshing in, viming a file, and hacking it a few times. These days, if you leave the app untouched for six months that 10 minute fix becomes 2 hours of fixing a broken docker build. :)

sakopov 3y ago

Around the time Angular came out with v2 and everyone basically realized that they either had to completely rewrite their Angular apps or spend the same effort to migrate to React (which was the new hotness at the time) I really started contemplating whether it's possible to stay sane while keeping up with the pace of change in both back-end and front-end paradigms. I ended up switching from full-stack to back-end dev. I don't know if it's just me, but now it seems like things have started to calm down and we're just iterating on existing problem sets and frameworks rather than throwing everything out and starting over. Does anybody feel the same? I actually think this is the best time to dive back into full stack dev.

boffinAudio 3y ago

Use what works. Ship code. Support your customers. Help them improve their lives. All other considerations are secondary. Including whether or not your peers approve of your code. Always remember: the User is king. Programmers are nothing without users, no matter what technology they apply to the situation. Sounds like you've shipped, and shipped often. GOOD!

flir 3y ago
But there are so many layers of abstraction between me and my user... (human layers, not software layers)
- boffinAudio 3y ago
  All the more reason for you to keep the user in mind while you wade through the crud.
- andruby 3y ago
  Do you think there are too many layers in between? Can you help reduce the number of layers?

JBiserkov 3y ago

> But it feels like I'm stuck in a Franz Kafka novel. Director of O(o)ps: Funny that you should mention that...

JBiserkov 3y ago
https://kafka.apache.org/ https://kafka.apache.org/
- TeMPOraL 3y ago
  Franz Kafka meets the Wild West.

agumonkey 3y ago

somewhere, deep in an archive room, a cobol developer is smiling

einpoklum 3y ago

This is a benefit (non-commercial) FOSS has over software authoring in commercial corporations. Developers get to call the shots, and usually, don't bend to such passing fads. > I don't even know how I would do it. Depends on the software you're writing of course, but the core would probably be some libraries with C (and maybe other language) bindings, some command-line executables, and anything else - above that.

andruby 3y ago

I can imagine this is frustrating and have experienced people wanting to push the "latest trend". My usual way to approach this is to ask them to explain to me the _why_. Why is this new thing better? What specifically is it better at? How? What trade-offs does it make? More often than not, they aren't able to properly articulate the why and the trade-offs involved. Sometimes they do fully understand the trade-offs and that leads to good discussions.

samsquire 3y ago

Thanks for your comment, I enjoyed it. I think the computer industry is in its infancy and we haven't really found the right solution to many problems, for everyone to adopt the same thing requires it to be a very good option. BSD sockets is used by everyone - it's that good. It reminds me of xkcd #927 about standards ( https://xkcd.com/927/ https://xkcd.com/927/ ) I would like a solution to the problem where library code is changed and it breaks code that relies upon it. I would also like an API description format that we can code against and doesn't break.

AdamCraven 3y ago

It's because a lot of engineers are learning to become better plumbers, not better engineers. Trying new technologies means you're mostly becoming better at using someone else's APIs - this is the path to eventual burn out as the churn continues. There is a better path - See through the hype. Ask those around you what's the downsides to this approach? And you'll often get blank stares... Why? Because they don't know either - And if they don't know the downsides, they don't really know. They are following the hype curve. Focus on the fundamental engineering principles and asking better questions - take the bottom-up approach and the reward is you'll find teams that aren't taken by the hype curve so easily. PS. There are a lot of good technologies that come out, but staying behind the hype curve a little helps you make better judgements over time.

nigma1337 3y ago

I have such a fear for this, that things i invest time/energy into today will be obsolete in half a year, and my time would be essentially "wasted". As others say, learning the fundamentals will, and trying to get some more general skill out of every tech fad. (although, full rewrite every 6 months is excessive imo)

wofo 3y ago

Wow, this resonates with me! I stopped doing full-stack development a while ago, and have since January been contributing to open source projects as a contractor (my next gig will be for ISRG, the makers of Let's Encrypt, :D). By working on open source libraries I get to tackle interesting problems without being bogged down too much by accidental complexity. It feels like the ideal solution to me (though it is difficult to replicate, as it takes quite some luck).

DarkCrusader2 3y ago

I am in the exact opposite,but equally frustrating boat. In last 5 years, I have worked at 2 Faang and a large hedge fund and everywhere they had extremely outdated stack or undocumented in-house stack or outdated undocumented in-house stack. Already derecated dependencies were pinned years ago and management won't let you modernize anything since there "no business value in it" and we need to ship a feature instead and if you still insist to refactor and modernize and something goes wrong, now you are personally responsible for the outage. The effort you spent successfully upgrading decades old stack won't count in your promo packet. There is just no incentive to upgrade anything beyond security fixes. Rewrite to chase the latest fad is frustrating but using technologies which don't even have online documentation anymore is equally if not more frustrating.

Quarrelsome 3y ago
I was stuck maintaining a solution using an abandonware internal transport layer built on technology that died in 2004 and an abandoned ORM on an EAV schema database over SOAP backend in 2022 with much the same "no business value in it" argument. "We're trying to sell the company so profit is of the most importance" transitioned into "we bought you because you make money". So instead we increased our maintenance exposure by adding more necessary features to the wobbly pile (or 'fixing' broken ones) as opposed to resolving the mistakes made over twenty years ago. Of course the dickhead architect would use articles like this OP as justification for why all of this wasn't a problem.
mathgeek 3y ago
Today’s beloved tech with well maintained docs is tomorrow’s institutional knowledge tech that companies rely on.
- pdimitar 3y ago
  Not my observation sadly. We've got some excellent 10+ years old tech -- Golang, Rust, Elixir -- yet a lot of companies out there holds on to C#, PHP and Java with an death grip. And I've worked with all of these. The newer stuff is better in every way except penetration (which is held back by bias and misguided evaluations of the word "safe").

Waterluvian 3y ago

After a decade I think I’ve concluded for myself that this is, for the most part, a self-inflicted problem. There’s really no need to keep refactoring or feel like others need to stop inventing new ways of doing things.

lumb63 3y ago

Have you ever considered a different portion of the tech sector? I work in embedded systems and this couldn’t be further from the truth. Things rarely change (because it took someone smart banging their head against a wall for a week to make it work) and if they do, they’re usually addressing real needs in the systems programming community. I see each change less as a fad and more as an additional tool in the tool belt. Take for example Rust, which is gaining traction in parts of systems programming. It addresses the direct need to stop overflowing buffers, create more strong typing, write less code to accomplish the same thing, and others. Accordingly, a lot of systems programmers are optimistic and excited about it. But everyone in the field knows C, and acknowledges C isn’t going anywhere. There are tasks for which C is better suited right now, and will be for a very long time. There’s no push to rewrite all programs in Rust. Sure, some are pushing for it, but it’s not a “this year is Rust, next year is <new programming language>” dynamic. It’s a “this is where we want to go, but it’s going to take us many years to get there” type shift.

otabdeveloper4 3y ago

Be thankful there are still people willing to pay you for bullshit jobs. Things will be tougher when management starts asking for real, measurable results.

ed25519FUUU 3y ago
Gotta make hay while the sun is shining.
BeFlatXIII 3y ago
Perhaps that would be the time to transition into playing rainmaker.

commandlinefan 3y ago

> Hype after hype, fad after fad, modern after modern, refactor after refactor And you're supposed to already know how to do it and give an accurate ~~estimate~~ prediction for how long it's going to take to do (that matches the amount of time they've already decided you have to do it). You're a _professional_ and professionals don't need time to actually learn how to do something new, they just know.

exhuma 3y ago

I've been in the industry for over 30 years and I absolutely get where you're coming from. It is an ever changing field and it can be exhausting. I hear this repeatedly from many coworkers (and workers from the same field). All I can give is some advice from my lengthy experience. Most of the changes happen on the "edges". Those edges are primarily three fold: First, the user interface: everything that deals with input parsing and formatting. This also includes protocol marshalling (Http, JSON, XML, ...) Second the data persistence. This involves choice of database or any other persistence. Including serialisation of your data. Any I/O really. Third, anything to do with deployment. This includes environment isolation, configuration management, process automation and so on. These the edges have nothing to do with your core application logic. You can reduce the impact of a switch to a new stack by inflating your core logic and shielding it from the rest of your stack. This is tricky and I still catch myself all the time doing it wrong. Because doing it wrong is tempting and easy. For example, consider a connection to the db: you will need a connection string. You can fetch that from an environment variable somewhere deep in your core code. But by reaching out to the system like that, you make that core piece of code dependent on the deployment strategy. Instead, you can move that part as close as possible to the entry point and then pass it down as function/class arguments. You can group similar operations together, close to the entry point. That way, if the dependent e strategy or the stack changes, your core code does not need to change. Another example is the case where your core code is dependent on a library from your stack. For example, when working with python and flask, it's easy to import "request" or "g" from the framework. But every piece of code relying on that will be tightly coupled to the framework and subject to change whenever the framework changes (either same framework with breaking changes, or framework switch). The solution is the same. Move those elements as close as possible to the entry points. In this example of flask, keep this as close as possible to your routes. But also keep your routes clean of core logic. Interact with the HTTP layer only and pass the values as arguments to your core. Finally, a similar situation, but much more sneaky and hard to spot is reliance on data types from your stack. Spotting cases where you rely too much on library modules can be done by investigating imports. But reliance on data types is harder to spot. Sticking with the flask example: the http headers are encapsulated by an object of the flask stack (werkzeug in this case). You may be careful and extract the headers in the route to follow my earlier example. But if you then pass the headers unmodified down into your core logic you will again be coupled to the stack. Instead you should extract only the values you care about and hand only those down to break the coupling. Finding the right balance where to cut the coupling is challenging. The more you cut, the better you will be shielded from changes. But the less you can benefit from pre existing implementations from the stack. Where to cut is ultimately a design decision. When done well, it will be far less frustrating to jump on the bandwagon of the latest tech. Not completely painless but far less stressful. Not least because you will have confidence that you didn't accidentally break core logic.

Hermitian909 3y ago

I have a partial solution to this I'm happy pretty happy with. First, is that I dove farther into CS fundamentals. This has made new fads a lot easier to deal with because usually they're recycling old CS ideas. React hooks is a good example. I wrote class components for many years, adopting to hooks took me all of a day because Algebraic effects were something I understood well. Second - I am firm about which tech I do and do not want to learn the specifics of. I understand the high level of kubernetes but will not be learning specifics.

red-iron-pine 3y ago

> We just keep changing and changing the same things again and again because that's the new way to do Capitalism doesn't work unless you have something to sell, and that's just as true for tech as it is anywhere else.

cyanydeez 3y ago

My man's ear never heard of corporate growth culture