I've had a very hard time with the Product Manager discipline. From the books and podcasts like Lenny's, it all makes perfect sense, but it seems like in practice it is as you described - they've inserted themselves in between and often don't represent either side well. It's lead me to develop product management skills myself, which are honestly incredibly useful in avoiding wasted effort. But it does make me wonder whether the dichotomy is worth it or if product management should be part of a senior engineer's skillset.
IMO a lot of the product managers inserting themselves and being useless is good old school project managers pivoting to the new thing and doing the same old stuff. Likewise I do think product management should be part of the senior engineers skillset. Its incredibly useful. Conversely, there are also tons of engineers that dont have this mindset and want a PM to tell them what to do and a barrier from the rest of the organization... which boggles my mind to be fair
That's an interesting observation. After some thinking, I agree. It was quite hard to get the PM that replaced me out of the "project management" mindset when she joined.
Also agree about engineering needing to have the PM skillset. Especially in startups.
I never really worked with a PM that was good at preventing wasted effort. Or even mediocre at it. Most assumptions I saw them making were incorrect, unless it was a VERY SIMPLE product.
To me this is something that engineering should be doing, just like splitting tasks and double-checking designs.
Of course not every engineer can do it, but some of us have been doing it, negotiating deadlines and deliverables our whole careers. So I don't really understand why our industry insists on having us throw away those abilities.
On the other hand, I've seen engineers make unilateral decisions that had completely unacceptable UX or ops impacts, that didn't align to the original design spec, and that they didn't think to tell anyone about until way down the road.
Everyone needs a counterpart to "trust but verify".
At my company, engineering managers are ultimately responsible for the deadlines and deliverables. It's an anti-pattern for PMs to also be the project managers - that is a bad combo and it should either be owned by the EMs or a dedicated role.
Frankly, for me, the best value product managers can provide is being the buffer and/or unblocker. I want other team C to do task X, because it unblocks my team and others, but somehow I can't convince team C to do it. Well, that becomes the product managers job. They _should_ know the path to delivery and understand why this is important and negotiate with team C to drop other stuff to deliver X. And they can tell anyone above team C why this is happening. And I have worked with some product managers like that, but unfortunately they are rare, and most just get bullied by stronger willed (obstinate) tech teams. It isn't an easy job.
I'm quite fortunate that at the moment I have a great relationship with all of our peer teams and we generally sort it out amongst ourselves. We don't have a product manager involved at all for the last few years.
As a PM I've always held the opinion that I'm genuinely not needed for a ton of work if the lead engineer is reasonably product-minded and understands current customers. Most existing customer pains are plainly evident and so long as it's not a wild amount of work, my job is to just give a thumbs up and move on.
Where it gets nasty is the new opportunities. Assuming your system of patronage at a company is a good one, there's a lot of work in finding new opportunities in the first place and testing them out. And often the cat herding of developers who do some of this (great!) but want to just run wild without testing any of their assumptions (not so great!) and trying to balance the excitement and creative forces with whatever framing is needed to satisfy others in the company. That gets most complicated when various stakeholders hold opposing positions on "what we should be focused on", and if you don't have a PM absorbing that damage for you, you're just going to end up doing that all day instead of building software.
One of the functions Product Management is to be an intermediary between the business/sales and Engineering. Sometimes you might have issues working with Product Management, but you don't want to interact and build features for a bunch of stressed sales folks, so they can make their quota.
It would be very hard for a company to build a sustainable business that way.
Having a downstream engineer to hate your guts is a good problem to have! It means your product succeeded for that long, and that it is still relatively well funded.
Highly recommend reading or listening to The Goal. The audiobook feels like a cheesy training video, but sort of in a good way, and the concepts are extremely useful. Plus, you learn the language it is more likely your business counterparts know, as opposed to talking about backpressure or queuing theory, which they may not connect with.
I use the concepts from this book all the time at work to justify a prioritized backlog and defend against a lot of work in process.
+1 vote for The Goal. Our operations research prof showed us the movie in class one day, and it's one of the few things I distinctly remember from my courses. It's teachings are crystal clear to me years later, although unfortunately/ironically I haven't been able to implement it in my life so well.
Work on solving problems using declarative languages and functional languages.
So, either Prolog, or Lisp.
Structure and Interpretation of Computer Programs is a good jumping off point for Lisp while also providing fundamental insights.
Prolog.. honestly, just google "basic" array problems and try and do them in prolog. It takes a mental shift, which is hard at first, and you feel silly not being able to count to 10. But learning how to think in this paradigm is useful - e.g. SQL is declarative.
Here's the thing. They are telling you they value these things as a signal. You as a candidate can be as frustrated as you want, but throwing a tantrum doesn't actually do anything.
I agree with you that writing in a non IDE and with no REPL is ridiculous. But... That's what they want. Clearly you aren't a fit for each other, why not leave it at that?
I think we've all wondered this at some point in our careers.
It's something you should never do. Off the top of my head:
1) Security (as has been beaten to death here)
2) Interface versioning. If you expose a generalized SQL interface to your consumers directly, good luck ever making a change to your database schema. You'll have no idea whose workflows you break. This high coupling becomes very painful very fast.
3) Abstraction. The way data is stored is often not the way data should be surfaced. What about application layer data integrity, things like that? This would require the frontend client to have far too specialized of knowledge as to how the backend works.
4) Optimization. How do you optimize for queries you don't control? Someone will craft something that can bring your database to its knees under load without even trying to.
Totally valid points. I think this can be solved by a change of layout. If you do use sql queries in the frontend but have a layer between your front and your database to map which queries are valid and how to map your queries to your own DB representation.
I too find ADHD to be a super power. We've been forced to adapt to our inability to pay attention to uninteresting things. But a lot of the day-to-day life doesn't really help you in the long run.
Props on vo.codes; I'm [refactoring my website](http://blog.con.rs/2020/09/11/mash-rehash.html), one piece of which is a "say" command currently powered by online dictionary. Seems a super simple fit to power it using your tool instead :)
I don't find it a super power. It's a trade-off. Very often education, health, finance and relationships get pretty damaged by it.
The upside is I don't do shit I don't find incredibly interesting. I'm perfectly happy as long as everything is on my terms.
The downsides have been my chronic inability to engage with anything not immediately interesting to me led me through a decade of very difficult unemployment, wrecking my health, being a terrible parent, and not being a great husband.
Though it's been a benefit to my professional software career, that has been at the expense of my health.
He has the right in the U.S.A. and it's only due him from the government. Citizens owe him exactly squat. I want him to need ACLU protection and I trust them to protect only the rights we all deserve.
He doesn't have that right in other places. He would be a non-citizen elsewhere, subject to foreigner's rights, except where foreigners get the same rights as citizens. Which is nowhere in the 1st world.
reply