Absolutely, see all the Github and Stackoverflow clones polluting search results all over the web. :D
272 karma · joined July 16, 2018
I used to work in a (Scrum) team where 80% of our projects were in maintenance mode exactly the way you described. It felt horrible to work there as an engineer (at least for me who enjoys creative processes and development).
You still get all the meetings, administration, rituals, debates over minuscule stuff - without delivering any customer value. There were entire sprints where most of the team hasn't shipped any useful feature, only fixing cryptic bugs in "other people's code" that nobody really cares about or keeping up with the latest changes in the NIH syndrome-ridden microservice environment.
Realizing that such a large organization can't be fixed, I moved over to a different company where the engineering team works more with a "product engineer" mindset. Probably the best decision in my career so far!
We're still "maintaining" software, fix bugs and refactor etc., but due to how Shape Up [1] works, creating customer value vs. maintenance is almost always 6 weeks vs. 2 weeks so 3:1.
But even for a Scrum team in a large org where some projects are passed around like hot potatoes, I'd never assign more than 50% maintenance mode projects to any team. This may not be the most efficient from the organization's standpoint, but it would probably do wonders for preventing burnout and employee churn.
We work on:
- The why: business/leadership, and to some extent, product determines key goals (KPIs, OKRs etc.) and markets we are addressing. Us engineers are only informed parties here.
- The what: product, and to some extent, engineering determines which features to build or improve to attain these goals in a user-friendly and sustainable way. We create projects and design sketches, assign time constraints to them.
- The how: engineering, and to some extent, product ships these features in a maintainable, scalable, performant and supportable way without disrupting existing user experience.
A very large part of this work involves creative processes and logical reasoning about business, UX, software engineering problems. (Of course, that's why I love it :))
Only a tiny amount of this work is "writing boilerplate code" or copying code from Stackoverflow - which ChatGPT is presumed to automate.
Of course, more senior engineers are faster at writing boilerplate, but their speed mostly comes from 1) knowing the existing codebase 2) using the right tools & abstractions.
Moreover, most of the risk involved in the process is not the time taken to write boilerplate i.e. working on something for too long - but rather working on the wrong thing, or doing an implementation that's too slow or hard to maintain (change, test, fix, extend, reason about).
All in all, when I think about software engineering from this perspective, I don't see AI automating it away anytime soon.
I could, though imagine AI being your TDD coder companion. You write some unit or acceptance tests for a service module and the AI generates the code for it. You'd still need to thoroughly review and test the code though. This would work well for basic CRUD/boilerplate modules, but not for anything involving business logic.
Nevertheless, this would still remain just a small part of a software engineer's work, in my opinion. What do you think?
Jordan Peterson - What Kind Of Job Fits Your IQ
What helped me a lot was 1. learning touch typing (a lot less strain on fingers & wrist), 2. using vim shortcuts which leads to less mouse usage (I'm just a basic user using basic shortcuts but even then it's noticeable) 3. exercising multiple times a week.
This is so true and so widespread that I haven't even realized it's happening. I disabled most push notifications on Android and have the phone muted almost all day. Still, I'm fighting with attention fragmentation, decreased memory etc. Nowadays most apps/web apps you open have a 'notifications' tab, menu item etc. creating yet another inbox for us. (Which we probably don't need unless it's work related or something.)
The framework defines roles (driver, decision maker etc) which helps with the process.
So a document (with a template similar to an RFC) is made by the driver. Contributors read and comment on it, then after all questions have been answered, a final meeting is held to make the decision along with the approver.
When the decision has been made, we go with it!
It's a really smooth process in practice, with very little friction. Way better than endless debates over and over on the same topic!
PR reviews are a way of learning from each other, keeping up with how the codebase evolves, sharing progress and ideas, giving feedback and asking questions. For example at $job we 90% approve PRs with various levels of pleas, suggestions, nitpicks and questions. We approve because of trust (each PR contains a demo video of a working feature or fix) and not to block each other, but there might be important feedback or suggestions given among the comments. A "rubber stamp bot" would be hard to train in such a review system and simply misses the point of what reviews are about.
What happens if there is a mistake (hidden y2k bomb, deployment issue, incident, regression, security bug, bad database migration, wrong config) in a PR that passes a human review? At a toxic company you get finger pointing, but with a healthy team, people can learn a lot when something bad passes a review. But you can't discuss anything with an indeterministic review bot. There's no responsibility there.
Another question is the review culture. If this app is trained on some repo (whether PRs were approved or not), past reviews reflect the review culture of the company. What happens when a blackbox AI takes that over? Is it going to train itself on its own reviews? People and review culture can be changed, but a black box AI is hard to change in a predictable way.
I'd rather set up code conventions, automated linters (i.e. deterministic checks) etc. than have a review bot allow code into production. Or just let go of PR reviews altogether, there were some articles shared on HN about that recently. :)
> Typing can be the bottleneck Agree! Learning touch typing (at 30 :)) was a big relief for my fingers and wrists. Also it's important to have a good mechanical or scissor keyboard so that typing actually feels good.
> Hiring is hard And it's like dating: you only get to know the people who you actually hire and never learn what would have happened to the people that you have rejected. That is some selection bias in the system.
Trying to put together a promotion packet with items or projects that are often orthogonal to "real daily work" feels daunting. "I need an x type of project or contribution for getting promoted" - while at the same time you might feel that if the company hired you fresh, they could hire you at the next level.
I'm not so fond of the phrase "software engineer" in that it's not a hard engineering discipline such as civil engineering. But companies need software developers who think and act like engineers. Engineers in general solve technical problems by applying methodical design, problem solving skills and having technical expertise.
Unless one works in a nonprofit or academic area, engineers are solving business problems for companies. Modern software companies with agile methodologies push engineers close to the business side, allowing them to add the most business value. Of course, many businesses suck at this and treat engineers like factory workers instead of creative individuals.
This varies a lot, depending on whether you're at a 10 person startup or at a FAANG company. Usually if the company has decent management then they have clear expectations of every position. In your case, this could be number of tickets solved or any other metric, but usually not lines of code. At least, I hope. :)
What I see in my experience is that most fully remote companies only want to pay you the local rate - which doesn't make a lot of sense. Some are willing to pay more, and only a few advertise paying equally regardless of location.
It's understandable because it just doesn't make much economical sense.
Obviously, I'd switch jobs any day for another 30-40% pay increase, and I'm curious how the last approach is going to get adopted by fully remote companies.
As (fully) remote jobs become more prevalent, that also pushes up local rates, though, and local jobs usually offer some better benefits because you're not a contractor. It's an interesting market!
Your question is very valid as the JVM can handle even thousands of threads (given the host OS can).
Having less threads does keep memory usage lower (as each thread in the thread pool has its own stack space). Also, it's more scalable because if using blocking code execution, you'll need to have one thread per concurrent request served. Lastly, thread starvation can become a problem with blocking code in case of delayed I/O or other failures. If that happens, the server becomes unable to serve new requests.
See this SO answer: https://stackoverflow.com/a/63490797
- Spring MVC (Java Futures)
- Spring Webflux (Reactor observables)
- Scala (Scala Futures & for comprehensions)
- TS async/await
- Angular observables
- React hooks (which combined with Redux, React Query etc. is a special approach to async programming.)
I think it's very important to understand that ultimately, async (non-blocking) programming is kind of a "hard problem" and there is no trivial solution for it. But we can't get around it because we must not block code execution: Javascript runtime environments are single-threaded (except workers) and the JVM has limited thread count, too.
Any senior developer has to understand how each of these approaches work and how they are trying to solve the issue of non-blocking code execution. I dare say that this problem area is one of the hardest ones during becoming a more senior developer.
In terms of ergonomy (developer experience) when it comes to simple chained non-blocking calls, in my opinion nothing beats async/await in terms of syntax simplicity. I miss them from Java & Scala! No indentation, lambda functions, flatmaps, monads or special methods/hooks needed. You just have the result of an async method right there.
I don't agree with the author that we shouldn't use async/await because it _looks like_ synchronous code. We _should_ use it to keep syntax simple and clean wherever possible!
The developer has to properly learn the language fundamentals (and how JS code execution works) and know that async/await is just syntax sugar over Promises and generator functions. If they don't do this, then having a Promise.then() chain instead of async/await won't help that developer write better code.
On the other hand, once they understand it, they can freely choose between async/await and Promises depending on what needs to be written.
For the general audience, let me drop some advice here that helped me during my job search:
- I knew what I was looking for (remote-friendly tech startups with their own product). I suggest you think this through as well.
- No Linkedin profile! Really, not needed unless want a corporate job. (Though I have a tiny and mostly neglected personal website which is appreciated by most companies.)
- Browse and actively follow dozens of job boards like the one in parent comment. DuckDuckGo is your friend. In a few days or weeks, you'll find out your 'taste' in terms of jobs that interest you and easily filter out mediocre offers.
- Draw boundaries and put your bar high. Know your desired compensation range and ask right away if not indicated. Reject take-home homework, leetcode interviews etc. if you don't like them. The interview process tells a lot about the company culture and you're also getting to know that company, not just the other way.
- Work on your resume! An investment that pays back like wonders. It also makes you much better prepared for interviews. There are some very useful books out there like "The Tech Resume Inside Out". Best $20 I've ever spent.
This way, you have total control in your job search and will have zero awkward HR phone calls. Though I admit that if you're looking for corporate jobs, a Linkedin profile might help. Also, if you're looking for MANGA etc. jobs, you'll need a totally different approach.
Shameless plug: I'm currently working for a no-code process automation tool startup called Process Street (https://www.process.st/), and we're hiring. :)
I used to struggle sometimes with DuckDuckGo but 90% of the time it now serves the same or better quality results.