261–270 of 430 posts
Whoever develops the “Visual Cloud” IDE for writing scalable web apps where everything “just works” will be about $10B richer…
I don't disagree with you and your examples are definitely over-engineering / busy work. In my experience a lot of it is driven by the desire for young engineers to learn a new language. If someone paid me to move something to Rust, I would do it. I heard good things about Rust and I would love to get paid to learn it. But has being a software engineer become easier or harder over the last 30, 20, 10, 5 years? I wasn…
Currently I'm involved in working on a "data intensive" app which munches a few dozen gigabytes of data and presents summarizations through a web based UI. Usually in the form of charts, time series plots, heatmaps etc. Adding small, incremental features to it is an ordeal. The "backend team" needs to mock and then provide the API endpoints, then the frontend team needs to "break down the work on the React components", then DBAs need to oversee the new queries. The security team needs to review risk impacts etc. One change is at least a few weeks of work.
Contrast that with the work that I did in 1998. It was a "data heavy" desktop application that visualized in 3d seismic data collected by ultrasound probes. The data volumes were in the order of hundreds of megabytes up to a gigabyte. The app was built as a desktop app using FLTK and OpenGL. It took about a day or two to roll out an incremental feature once we knew what was being asked. By two weeks it was in all of our customers' hands. While there was no Stackoverflow.com and we relied primarily on offical documentation with the help of "Effective C++" and "More Effective C++" the build/debug/test cycle was much shorter, the tool chain was much simpler and more transparent, the UI toolkit was much easier to grok and even though it didn't have an "elegant state framework" somehow we made it work well without turning it into a mess.
As an industry, we gave up on localized desktop processing in the name of "consumer preference" (or so we were told) while we assumed an immense amount of complexity in order to server the same computation from a centralized place.
Earlier quoted context omitted.
Given what you explained, it seems to me that the cloud was an excuse given by the new overlords to just get you out off the way. Cloud is fashionable now, but any excuse would work for them. This seems to be a power grab.
I don't think it's about power. Because of the way the organization is structured, I am isolated from the IT department. Moving me out brings no advantages to either part of the org. In fact, it's probably a disadvantage to IT because it has to burn three people from its allocated headcount. Where previously, it had a bonus person that didn't come out of the IT budget.
The way I look at it is: there are more tools in the toolbox than ever before. Which makes our judgement (the thing they really pay us for) even more important. Kubernetes, for example, is a specific solution to a specific problem. The solution is complex but so is the problem. If k8s give you the right trade-offs for your situation, then it’s not busy work. Of course, there are plenty of project where judgement Is t…
I spend more time trawling GitHub issues to find workarounds than I do actually using the tools.
I think the market is always right. As complexity increases in areas as you describe, it will create opportunities for solutions that simplify things. IMO, it's one of the reasons that Phoenix LiveView is so appealing for people because it removes so much complexity from building otherwise complex tooling. I actually just had to come face to face with this because I've been developing a lesson plan to teach my son to…
How long does it take to be always right? A lot of these comments at best imply significant lag, and at worst imply the market is perversely wrong.
For example, we have deliberately stuck with a single Node.js/Next app in a single repo using Postgres running on Heroku. We are 5 engineers now and plan to keep it that way for the foreseeable future, even as the team grows.
There is some complexity we probably don't need – the JavaScript ecosystem is notorious for this – but what we use is all reasonably boring tech at this point, and it allows us to stay productive as a team, focusing on delivering value instead of just maintaining things or chasing trends.
The way I look at it is: there are more tools in the toolbox than ever before. Which makes our judgement (the thing they really pay us for) even more important. Kubernetes, for example, is a specific solution to a specific problem. The solution is complex but so is the problem. If k8s give you the right trade-offs for your situation, then it’s not busy work. Of course, there are plenty of project where judgement Is t…
Promotion based architecture is self fulfilling prophecy at least in BI/ data world. I see everybody around me moving to cloud, without really good explanation why. Only reasonable thing I can see as an pattern is that cloud experience on top of data things gets paid 30% more. It made me consider cloud a lot. I was considering switching to cloud, just so I can put in my CV "experience with migration to cloud". For ne…
I believe this issue was discussed about 7 years ago. I believe this article still holds true. https://pingineering.tumblr.com/post/116038532184/learn-to-s... (let me know if someone has a better link.)
I’m deeply saddened that they chose MySQL as their hill to die on. I understand why, but boring technology doesn’t have to corrupt your data silently by default. As for better links, I’m sure the concept of “choose boring technology” evangelises and explains the broader point that your article makes: https://boringtechnology.club/
Sounds to me like you've worked at trendy tech companies and want to keep working at trendy tech companies. That means you're going to have to work with trendy technology. A massive amount of companies, maybe even the majority, don't do this. They use what works and upgrade when needed, not when its cool to use the new thing. They just don't tend to pay like trendy companies and don't look as good on a resume as tren…
As someone who purposely -doesn't- work at a trendy company, it seeps in here too. People abuse us to get jobs at those trendy tech companies, basically. Understand we have a relatively small web presence with not a lot of traffic. High dollar, low volume type stuff. About 6 years ago someone decided to move all our stuff to self hosted kubernetes and microservices, because reasons. As you may imagine, he took a job…
Sounds like your managers are either looking at those trendy tech jobs too (and want to have the buzz words on their resumes) or they think the trendy tech will attract candidates.
HN's perspective on FE Development is that it should be a meager skill that can be on-boarded with ease, and there is frustration with frameworks (most notably, React), because what was once done with HTML/CSS and a sprinkle of JQuery has exploded into an actual field and specialization.
And, personally, I think it's warranted.
The explosion in demand for what the front end requires is just in correlation with the specialization of the field.
15 years ago, we were just doing blog posts with form submissions, now, we're trying to pave the way so that applications like Photoshop can be accessible in the web.
HN is getting old. There's no doubt about it.
And the young ones are starting to lap you guys.
I just hope I don't grow as bitter and hostile when my brain no longer can pick up new esoteric material with ease as some of ya'll.