mruniverse

The PMs want to get features out asap. Test out ideas asap. They want to get new work into production.

The engineers want to build features that are well thought out, low maintenance. This takes time.

PMs can get engineers excited and get them to want to work quickly and worry about the little stuff later. The problem is the little stuff that needs to be fixed never seems to become a priority because the next new feature needs to go out. But only the engineers are responsible for the fixing.

If you're a CTO, do you trust your person A or B? If you're not technical what do you base it on? What are you judging?

Are you judging based on their personality? The number of brownbag talks? The feedback from peers?

What you want is for someone to know how things work. And if they don't know, know what to ask. You want someone who's done it before. They have to be technical.

You want your chief of plumbing to know how to plumb. You don't want them to just be familiar with plumbing. If so, the next thing you know a good salesperson will talk them into replacing all the pipes with new wonder-pipes with space-age wonder-clamps.

Second task is to come up with a plan to your refactor. Break it down with time estimates, etc.

As far as the "great hacker but a mediocre manager" thing, same can be said of Parag... "good CTO but mediocre CEO".

And that they understand agile to mean the same thing as the engineers. That is to say to small deliverables within a short period. Review the small deliverable with client, make adjustments, then repeat until final product is done. Basically get things working a small piece at a time. Change directions if needed. Don't boil the ocean.

What usually happens is that the clients take "agile" to mean changes on-the-fly AND quick delivery of final product. They also usually prefer the waterfall deadlines, because then can line things up for Q2, Q3, etc.

I think a big reason for the disconnect is the word "agile".

I think of this when managers come up with different requirements during the project. If the requirements seem to make the product better, I'm all for it. I like to work this way and they pat me on the head for being "agile". But I always end up kicking myself when they ask why the project is taking longer. I fall for it almost every time because I like to tinker.

I think you're going to get more of the same. If not directly from your manager's boss, it will be passed down to you. And again you will be puzzled. It won't quite add up and will feel like you and your bosses are on a different page.

I would make sure to stay at least a year, then find something else.

Good front-end devs are usually stronger with browser-side code. I usually see smaller html/css files, flex and grid being used and a11y reader and keyboard-nav issues taken care of. And the javascript is small and generalized (not much hard-coding). With full-stack devs I normally see a mess because they are just java programmers.

I guess that depends if you're the injured party. If not, that might make criticisms seem "nit-picking".

The hockey puck mouse was horrible though. Was that an Ive design?