If your organization has one API written in Node, another in Java and third in Python without any reason, then yes, all the problems are nails. And sadly, I've seen this a lot.
I've have limited success using codex to do code conversions for multiple projects into one standard team language. I suspect this will only improve and is how this "problem" gets solved soon'ish.
I was thinking of doing something like that, but how does it work for the company in the end? If they vibe coded their project and now have shitty code full of bugs, you come in, fix the bugs and organize the code better and that's it? How do they continue to maintain it if they didn't have the knowledge to set it up in the first place?
They would try to hire and/or build the team they need to move forward, if they have the money.
Knowledge is usually not the problem, it is the shortcuts(or short-term decisions) that got them to a place where they can no longer operate the platform they need to survive. Often this is the cause of prioritizing velocity over anything and everything else. This is choosing the do it fast and do it cheap options with the assumption that it is always correct. That assumption of course is almost never true.
By the way, most cases where I've seen this there's usually an investor involved and they need to impress them.
The pattern I've seen repeatedly in real life is that a company does something they don't expect to be important and impactful, cutting every corner they possibly can to shovel out something that minimally meets the requirements. And then that software surprises everyone by actually being wildly successful, and now they have to support it and modify it to a state where they can build upon it. Which might be hard if the product is an unholy mess made by people who knew little of what they were doing and cared about it exactly as much as they got paid for it (that is, not much).
And cutting every corner to get the cheapest possible product out might not have even been the wrong call! Presumably most things made this way fare just as well as they were expected to and die quickly after being made, not spending scarce resources on making them better was probably the right thing to do.
It just sucks when you end up having to maintain strict backwards compatibility to something that was made in two weeks by one guy who took every shortcut on the way to duct-tape together something that technically does what was asked for. (Yes I'm thinking of you, javascript.)
This. Based on what I have seen so far in my company so very anecdotal.
Assuming they know and/or have the capability to do it, between the cost of correcting the issue and push to use AI into everything meaning raising any issue now, politically speaking, is a direct criticism of someone major VP pet projects. I personally simply started to log stuff.
The first thing they need to do first is acknowledge there is a problem to begin with. I am so glad I am not an actual programmer though. It would drive me nuts.
There's definitely a lot of politics involved in such projects. So I've learned that a break is necessary between major engagements to decrease the risk of burnout.
The environment that creates "rescue" projects is usually not one where long term thinking is prevalent. It would be a pet project of someone who's still there or someone who left but where the ultimate decision maker is still there. Either case, you need to walk on egg-shells and be mindful that dealing with the technology problems is the easiest part of such an engagement. I'm not ashamed to admit that I've learned that lesson the hard way.
That's a good question that I sometimes ask myself. But if you want the money, you have to do what it takes. There's a limit of course and lines that I do not cross(illegal, unethical etc). There were plenty of times where I had to say that this is not going to work and chose to end the relationship with a handover. During those times, the technology wasn't the problem.
I think if they are interested on fixing it it's because the project provide business value, so then now it's worth it to build the software development team or make a contract with software development agency
I mean, of course exercise isn't going to fix your vision. But if your vision is going to degrade, you can still choose if you want to live as a fit and healthy person who needs reading glasses, or as a person who has aches all over, is in bad shape, feels tired and like shit all the time, and on top of all that needs reading glasses.
I am in my mid-40s, don't do regular exercise, and still dont feel like "shit".
Really, this "motivation trainer" rhetoric coming out of obesity-infested America is tiring.
You sound like there is only two extremes: Couch potatoes and people that run a marathon every weekend. There is actually a middle-ground. And a not-so-small group of people is actually comfortable in that middle-ground.
You can feel relatively healthy without running around like a wound-up monkey. Step on, don't eat too much. Then you don't have to burn calories to get rid of extra fat. It almost sounds like "uppers and downers"... Mind you, I am not arguing against sports in healthy doses. But whenever I read or talk to fitness fans, I feel like I am talking to a person following a cult.
It’s not that difficult to hit basic exercise targets as part of your lifestyle without realizing it. Going from an apartment to a two bedroom house involves a great deal of climbing up and down stairs per week. Taking a dog on a walk involves you yourself walking etc.
People talk about being a couch potato because there’s a massive difference between activities that involve passively sitting and things like gardening that require occasional movement that adds up over time.
most people who think they are in the "middle ground" are actually unhealthy, because they end up comparing themselves to the outliers of the morbidly obese or those with absolutely terrible diets
You are proving the original point by again focusing on the extremes.
Do you have any data/research to back up your claims that people who think they are in the middle are actually unhealthy or that they compare themselves to outliers?
The Dunning–Kruger effect should be in play here where people overestimate how fit they are. However, it really comes down to defining where the acceptable middle ground is. The majority of adult Americans are overweight (25+ BMI) and that’s been normalized with morbid obesity being considered excessive.
“Research suggests that changes in the social perceptions of what constitutes overweight and obesity may contribute to the increased prevalence of obesity (Burke et al., 2010; Johnson et al., 2008; Johnson-Taylor et al., 2008). The growing prevalence of overweight and obesity could change the subjective threshold for what most people consider a “normal” weight level, thereby resulting in under-detection of overweight and obesity (Robinson, 2017). This explanation highlights the fact that social context affects weight perceptions (Hammond, 2010; Leahey et al., 2011b; Mueller et al., 2010; Robinson and Kirkham, 2014) because individuals adjust perceptions of their own weight based on the weight of those around them (Ali et al., 2011; Burke and Heiland, 2007; Maximova et al., 2008; Robinson, 2017)”
https://pmc.ncbi.nlm.nih.gov/articles/PMC6304710/
The comically fat guy on some old shows looks reasonably normal today. However being overweight with a high fat person simply isn’t healthy. The healthy person who doesn’t exercise much should be quite thin rather than simply replacing muscle with fat and keeping the same weight.
I relate somewhat to this and those were two reasons I didn't exercise for a long time.
1) Feeling like shit: I found out that when I felt like shit it was a sign that I was going too hard. After falling off the wagon a few times because my workouts were so unpleasant, I decided that instead of quitting, this time I would keep going to the gym but just exercise like a pussy. Turns out light to moderate exercise is dramatically better than no exercise. Exercising like a pussy has eliminated all the aches and pains I used to have, fixed a wrist that was developing carpal tunnel, fixed a bad knee, lowered my blood pressure by 12 points, etc.
2) For me cardio is mind numbing, but weight training isn't bad. I mean weight training is basically doing a set, then sitting around for a few minutes messing with your phone or listening to a podcast or reading a book or whatever, then repeating. This is why most of my exercise is weight training, and my cardio sessions are 20min max. It works just fine, you get a ton of cardio from doing compound lifts. Also my gym has a jacuzzi where I can zone out after my workout and listen to podcasts, this turns the gym into the highlight of my day tbh.
"Pussy exercise" sounds like you're doing everything right for building your fascia!
As fascia stabilizes joints it explains your joints getting better. Focus on soft, bouncing movements if you want to regain, enhance or simply conserve fascia tissue.
Also, with time, it enables you to do with heavier weights and plainly brings back joy to moving. All the best.
It would be fine for short drives, but anything longer than 10 or 15 minutes needs to have smarter handling of these larger video files, which would quickly swamp your storage. Think about using it everyday for a 30 minute commute back and forth.
Don't know anything about Scala. Kotlin has null safety and a bit cleaner syntax, but other than that, I don't see too much advantage over Java for backend. In Android, Java is still lagging behind a lot. Also, Jetpack Compose, a declarative UI framework is Kotlin only. Kotlin is also working on wasm (so is Java I think, but Kotlin has working examples with wasm GC) and Jetpack Compose is going multiplatform, including wasm. This video has some examples in description https://youtu.be/oIbX7nrSTPQ
Reddit mobile site does this when you tap a post. It drives me nuts. Then you have to hit back, which refreshes Reddit and brings you back to the top. I think it’s intentionally designed to get people to switch to the app.
I doubt they'll care. By that time, they'll be confident that whatever loss they incur by killing old. will be worth it for them. If there was an actually significant user base using old., I imagine "regular" Reddit would look a bit different than it does.
"I have several side projects where I use a simple Spring Boot backend and I feel I can focus more on the fun part (solving problems)."
I tried to do side projects with Spring Boot and I also worked with it professionally. I never got to the point where I can focus on just solving problems, I'm always fighting with the framework, looking for how to do certain things in the depths of blogs and stackoverflow because I can never find what I need in Spring docs. I actually find it interesting how some people seem to be very productive with it, while others have issues similar to mine.
I like to use React for it's component system. Those components don't even have to be reusable, I just like working with them, it's way easier to separate and organize code and it makes me more productive when I have to find and change anything. I don't like huge html files. If I need static sites, things like Nextjs and Astro are great for that.
Where do huge HTML files come from? Using traditional templating engines does not at all mean, that you will have huge HTML files. Traditional templating engines like Jinja2 allow splitting up templates in very modular ways.
Separate template files can be organized neatly into directories and subdirectories as well. Templates in general can reside in their own "templates" directory and do not need to be mingled with the code. It is very clear where to look to find things.
The idea is, that you have modular statically rendered pages and then on some pages also serve a frontend framework for interactive components. I know that at least VueJS was able to be run like this. In the end, even with React or whatever other framework of its kind you use, you are still serving some HTML and some script tags, which may or may not include React, VueJS, or whatever else is the thing at the time. I am guessing, that React can work the same way that VueJS can, by simply including it on some rendered page templates, but I have not tried it.
Writing a single get endpoint that returns string is easy in almost any language/framework today, you didn't really show anything with it. The real pain starts when you have to add database connection, migrations, auth, security and all that.
Yep. I build glorified CRUD apps in NodeJS + React, my friend works on some embedded C++ stuff.
- My working hours are way more flexible. I pretty much only have to attend meetings which are rare, so I can basically work whenever I want during the day. That means that I can go to the dentist and stuff like that without taking the day off. She has pretty strict hours.
- I can work from anywhere, only requirement is decent internet connection. She has to go to the office because that's the only way she can actually test the code she writes for physical devices.
- My salary is basically double of what my friend makes.
She's currently learning JS so she can just move into web space. If someone can choose between easier job with much better salary, benefits and working conditions, they will do that without thinking, unless they reeeeeally like C++.
Probably less related to C++ as a language and more so an "embedded" issue or down to the specific industry that your friend is in.
E.g., there are hundreds of C++ devs at my company that have the same work from home options and flexible hours as their frontend peers. So these jobs exist.
Why is API design/backend engineering the only software discipline that gets maligned like this? These are bread-and-butter operations. I don't mean to attack you, just noting that I never hear anyone talk about mobile development in the same way, for example.
A lot of CRUD app development feels like tedious, repetitive busy work. Data entry was a solved problem in COBOL if not earlier, it's not gotten any harder in the decades since, it's just gotten more tedious.
There are generic data entry tools that solve the entire class of problems in that space. In web tooling there are things like Django's Admin app. In "the ancient world" there is Excel for good and bad and ugly. But those aren't "branded" enough. Those aren't "experiences" that some UI designer has sweated and cried over until they were beautiful. Those "don't understand the domain" or "don't support our processes" or "don't know that we are a special snowflake with special snowflake data" hard enough.
So you just rebuild the same types of things over and over again every time the UI designers get bored or the company decides to use a slightly different version of the same data. Sometimes it can feel a bit Sisyphean.
The same can be said for dentists or architects or chemical engineers or whatever. Teeth and houses and oil refineries are “solved” problems in that we know how to do it.
But each instance is a little different. Each customer wants their flavour of the problem solved.
Long story short: don’t get into a line of work if you don’t like churning out multiples of the same thing for years.
> The same can be said for dentists or architects or chemical engineers or whatever.
- Dentists have dental hygienists that do the day-to-day grunt work so that dentists can focus on the real problems/exceptional cases (cavities, root canals, etc).
- Architects build the plans, but they leave it to construction workers to actually construct the project.
- Chemical engineers generally work with staffs of chemists and other roles that the take the engineered solution and apply it day-to-day.
Right now, software uses the same job titles "for everything". There's (perhaps intentionally) no differentiation between the people expected to solve the hard problems/engineer the tough solutions and the people hired to plug-and-chug their way through their 15th yet-another-CRUD-app that year. There are complaints in the surrounding threads even that some of the "drone work" pays better salaries and has better hours/corporate cultures than the harder stuff. It's an interesting "upside down" situation compared to even just the three fields specifically referenced here.
I went to an engineering school with the expectation that I would be doing software engineering not just in name but in role, but most of the jobs I've ever worked were paying me to do not that. I certainly know friends who are chemical engineers that also perform the role of chemists for their companies, but those are clearly distinct enough job descriptions with a big enough salary distance that those companies know that any hours my friends put in as chemists rather than their hired job is over-paying those hour rates by a considerable enough amount that they have reason to hire cheaper chemists. I have never seen a software job consider that they may be hugely over-paying a software engineer to do "software development grunt work". Without truly separate job titles and salary considerations that is forever going to be opaque to the accountants at companies.
Long story short: other professions clearly delineate between jobs that are (creative) problem solving and jobs that are more "grunt work" like Ikea-assembling CRUD apps. Why don't we?
> Long story short: other professions clearly delineate between jobs that are (creative) problem solving and jobs that are more "grunt work" like Ikea-assembling CRUD apps. Why don't we?
Is that even possible? It's difficult to separate grunt work and problem solving, because you often need similar levels of context to solve both. They also tend to intertwine a lot.
Of course it is possible. There's just currently more reasons for companies not to care and not to do it than to do it: Capital P Professions have education requirements and licensing/certification commitments. Capital P Professions have ethics bodies and mandate professional standards. Capital P Professions have professional societies that sometimes can organize industry wide negotiations (not quite to the same extent as Unions, but kin to it).
I don't think it is a technical problem keeping software from better sorting its various types of jobs by difficulty and types of problem solving. I think it's far more corporate politics and sociopolitics and a general lazy preference for the current status quo (because it works to company's favors in terms of job description opacity and keeping pay scales confused and under-valued and, uh, not having to worry about "quaint" "old timey" things like professional ethics investigations).
Software Engineering is also a capital P profession on the countries where it is a professional title, and not something that one is allowed to call themselves after a six weeks bootcamp.
I think there's truth to this but you're glossing over details that are critical. If the amount of variation between products were countable and predictable as you paint it, then you'd only need designers and a cms specialist who can configure the product. As a web shop, this is much cheaper to do. There are tons of website builders today which has saturated the "simple" market, but "intermediate" customers have small variations that still need custom integration work.
All in all, saying that dev work is repetetive is a hard sell, because if it was, you could just automate it. And we clearly haven't automated even the space of medium-complexity web apps yet.
I pointed to two clear examples where we as an industry have automated it (Django's Admin app, Excel), and I could name tons more (Access, Power Automate, InfoPath, Power Apps, SharePoint Apps, SharePoint Lists, and those are just the Microsoft side of the list; you mention CMS specialists and we could list out of the box CMSes for days).
> still need custom integration work
Define "need" here. I already threw some shade at this by accusing many companies of thinking their every need is a special little snowflake that needs lots of custom tweaks and custom specifics. In my practical experience so much more of that is "want" rather than "need". They want to feel special. They want to feel like they have control. They don't want to pay for the cheap out of the box CMS because it might imply to their executives and shareholders that their entire business is cheap and easily automated.
Some of these CRUD apps are truly "John Hammond syndrome" apps: they want the illusion that no expense was spared. (And just like John Hammond sometimes confusing building out the gift shop and adding fancy food to the restaurant in the Visitor Center with spending enough on redundancy among the critical operations work and staff.)
As someone who has done .NET, C++ embedded, Python and NodeJS, I have to say that picking up NodeJS and creating APIs at scale with full automated nightly test suites using docker and postman/newman was very easy to learn and very fun. Python is up there as well but I had to work on Django and not some of the more simpler api frameworks that looks nice.
It's not maligned. I've worked on some complex backends some time ago and I would never call those glorified CRUD apps. But my current project is basically Node backend with almost zero business logic. You hit GET endpoint, it returns someORMRepository.find('events').where({ category: 'FUN' }). That's it. React side displays a table with some basic sorting and filtering. Editing and creating and entry is just a basic form. I don't see how else could I call it, it's not that much different from CRUD demos you see in blog posts.
> Why is ... backend engineering the only software discipline that gets maligned like this?
Where do I even begin? The intrinsic difficulty of most backend problems is very low - read some customer data, save it to a database, call an external API, send data back to customer. The only effort you should have to put in is fighting boredom.
The web dev industry managed to overcomplicate this task to the point where even small startups targeting niche markets have architectures inviting race conditions over distributed systems with tens/hundreds/thousands of working parts.
It doesn't have to be like this. The problem is that your average web dev doesn't know how to scale down (optimize for space/memory/disk consumption), so instead they scale up (more computers). Scaling up isn't necessarily a problem if you know what you're doing, but I've seen a bunch of super-principal engineers regurgitating the popular scaling up buzzwords without actually understanding the tradeoffs. They choose a technology because Google is using it.
It's not fun to fix deep systemic problems in distributed systems when the system has already been running for a long time, and there's a large number of devs working on it. You can't just say "ok, everyone stop working, for a while, we'll take a couple of months to rewrite everything, the customer can wait".
What's worse it that this type of issues would've been obvious from the very beginning to anyone mildly curious to imagine what the future of such a system would look like.
Another type of common issue is slow queries, and the common "solution" results in eventual consistency.
I'll stop now.
> I never hear anyone talk about mobile development in the same way
Mobile development is just as bad, maybe worse. One overly complicated framework (Android), and another one that's fenced-off to non-Mac developers.
