1,817 karma · joined July 29, 2022
- not enough tech: so you don't get to work on the nice and interesting stuff
- it has it's management part: so you get to work on the boring stuff
Did you get a salary increase as well? And if so, would they decrease your salary if you go back to IC? If you keep your salary increase, that's a good deal. If there was no salary increase -> that wasn't a promotion! If they decrease your pay -> find another job
To each their own. I prefer to maintain a bad system because:
- I can make it better
- If something doesn't work as expected it's because of the current state of the system, not because of my lack of ability
On the other hand, I don't really like to maintain very good systems (crafted by very intelligent people) because:
- There's little I can do to make them better (I'm a regular Joe)
- If something breaks it's because of my ability as a programmer (all the shame on me)
So, it's like playing in two different leagues (but the paycheck is rather more or less the same, so that's nice).
The best he could have done is to apologize, though, and handle it legally.
It's probably because Amazon has all the money in the world they need to develop their products, but I would expect to launch a new product with some minimal but strong features to attract customers. Q offers 40+ built-in connectors from day zero. Like I can imagine the engineers/managers working on connector number 25: "Man, we have implemented already 24 connectors and we don't even know if the product will be a success or not...".
Na. We'll be able to do more with less... but the amount of work to be needed will increase, hence more people will be needed as well. Same old story. Compilers didn't get massive people fired.
But this is not the norm. In order for company X to hire people from a different country, it is necessary that:
- company X hires contractors/freelancers. The vast majority of people out there in IT work as employees, not as contractors
- company X needs a branch in that country. This is rare
- company X hires in that country via an intermediary company. Not as rare, but usually it's not worth it
Not even in Europe countries hire people from other countries that easily. It's more common now after covid, yes, but it's definitely not "let's hire from country X developers 50% cheaper!"
- amount of current grunt work: X
- new tech Z appears that makes X be reduced to 0.1X
- at the same time Z enables new ways of doing things. Some things become grunt work because they are a byproduct of Z
- amount of current grunt work: Y (where Y ~= X)
- ...
If the technological progress had stopped in the 2000s, then all the grunt work (originated in the 90s) would be esentially zero today. New tech just brings automation and grunt work. I don't think we will live in a society where there's practically no grunt work.
The most recent example is AI: there are AI tools that generate sound, images, video and text... but if you want to create a differentiating product/experience, you need to combine (do the grunt work) all the available tools (chatgpt, stable difussion, etc.)
> MAKE USE OF THE CURATED SELECTION OF DRUMS, BASS AND KEYS THAT COME PRE-LOADED ON YOUR K.O.II.
Question: would I be stuck with their pre-loaded curated selection or is there any way I can "upload" any extra dum/bass/keys and use them?
Whenever I think of how planets move around a star, I always think "Ok. So, I imagine that at some point the universe should know the distance between planet X and star Y, and also, probably, maybe, it should know their masses... but that data is nowhere defined (that we know). So, is the data computed 'on the fly' every $minimal-unit-of-time?). Perhaps the universe doesn't need to know distances nor masses, though.
Obviously, we need to find contemporary analogies:
- the other day I opened (manually) a bunch of Linkedin profiles (each in one browser tab). Apparently, Linkedin thought it was a suspicious activity and blocked my account for some time (I don't remember, but in the range of hours). Luckily me, I still got my account... but it would be hard to find jobs and keep working connections without Linkedin. I dodged the sword
I'm sure one can find similar examples (or worse) for all the big companies out there (never heard of "google banned me. help!"?)
In every company I have worked for in the last 10 years, the layer in between business experts and software engineers has been always: the manager (either product manager or eng. manager). It's a bottleneck. The flow usually goes like this:
business expert -> manager -> engineers -> manager -> business expert -> manager -> engineers -> ...
Whenever the manager comes with "requests" from the business side, we end up with tons of questions because everything is half-baked. Manager goes back to business with our questions and comes back with some answers, but usually that just generates even more questions. In this way managers feel empowered. There's no way they can let the engineers just talk with business (otherwise the managers would feel like they are not contributing in anything... which is kinda right if the engineers are more or less professionals).
Off-topic: is it really like that in the US? (I'm assuming he's from the US). Like, if you get stuck for a few days, you start to worry about being fired or reprimanded?
Edit: on summers I usually sleep one hour less (because it's too damn hot in the morning). I hate sleeping during the summer.
- It's difficult to sell good engineering work to them, and hence salary increases happen (if any) but on the lower end.
- With the typical excuse "Eng. managers should empower engineers", eng. managers do around 1% of the job when it comes to start big projects. The whole load lies on the shoulders of the senior engineers. One would expect that an eng. manager is probably the individual in the team with the most experience (both in engineering and in management), but eng. managers usually don't spend time trying to understand the systems their teams own. A classic example is: an eng. manager who knows very little or nothing about, let's say, Node+js, even though he has been in the team for over a year: their excuse? They only care about the "high level design decisions, they don't need to code anything". Funny thing is, the "high level design decisions" are done by senior engineers
Good engineering managers are invaluable, though. But in 80% of the software teams out there we either have bad eng. managers or average ones. In summary:
- good eng. managers => heaven
- bad eng. managers => it's ok. Since they are bad, they most probably will be fired or the whole team will know quickly how bad they are
- average eng. managers => hell. Because they are not "bad", so they are not fired. They think they are good and all.
Been there, but I don't see it as a problem. On the contrary, by being the only one who cares, I got promotions and salary raises. In the few situations in which I didn't get more than my peers (who didn't give a damn), I resigned.
So, at least for me, being around people who don't care that much is an opportunity for me to by working normal hours (9-5) and caring, get a salary bump.
My v1 would not pass your interview. My v4 would be a world-class solution. Fair enough, you are not looking for my v4, and rightfully so I should fail your interview (because I bet there be some people out there who can produce world-class solutions without relying on external sources)
Code reviews are way more subjective than writing a piece code (at the end of the interview session, if the code works, then that's a huge thing already).
If I highlight something like "Perhaps we could inject that dependency, instead of harcoding it": sure, that seems probably the most correct assesment, but again, what if we are dealing with a really small project and hardcoding the dependency is the best way? Same goes for variable names ("i" is too short? Depends on the scope, right? Well, probably it depends on the interviewer's mind), what about composition vs inheritance? Again, subjective as hell. And don't let me get started with anything related to microservices vs monolith...
Isn't it known that what takes the most time (in software engineering) is to understand a given business problem, decompose it in manageable chunks that can be worked in parallel, then provide a solution for each chunk, and then maintain such a solution? Using the IDE to write the actual code, sure, it needs to be done, but it's rather the part that takes the least amount of time. So, if any their slogan "Build software faster in an editor designed for pair-programming with AI" is rather misleading. I actually spend more time reading code with my IDE than writing code.
For a moment I thought that what would come after that sentence would be "... Use Jetbrains IDEs instead"