You have to know how to drive the car
seangoedecke.com
You have to know how to drive the car
1–10 of 60 posts
Re: You have to know how to drive the car
#2There are two things that drive your value (aka salary):
1. Do people like working with you 2. What would a competitor pay to hire you
The driving factor in the first is your UI, the second your skills.
Re: You have to know how to drive the car
#3Actual title: You Have to Know How to Drive the Car.
Actual theme: LARGE tech companies suck.
Declared subject: you have to know how tech companies work
Actually subject: you have to know how large-and-or-disfunctional-and-or-sales-or-finance-bro-led-companies work.
Tagging @dang re title.
Re: You have to know how to drive the car
#4> You ought to know that crushing JIRA tickets is rarely a path to promotion (at least above mid-level), that glue work can be a trap, that you will be judged on the results of your projects, and therefore getting good at shipping projects is the path to career success.
Notice that the author didn't write "getting good at delivering value." They wrote "getting good at shipping projects" because
> Shipping is a social construct within a company.
Delivering solid software that helps people get work done is a platonic ideal. Unfortunately there are many companies that value whipping stuff out the door more highly. As corny as this sounds the iron triangle ("good, fast, cheap - pick two") is a thing for a reason. Crapping something out as quickly as possible and leaving others to deal with the fallout of a bad data model and chaotic on-call isn't something to be rewarded but it's how many companies seem to work.
Re: You have to know how to drive the car
#5> You ought to know that crushing JIRA tickets is rarely a path to promotion (at least above mid-level), that glue work can be a trap, that you will be judged on the results of your projects, and therefore getting good at shipping projects is the path to career success. Notice that the author didn't write "getting good at delivering value." They wrote "getting good at shipping projects " because > Shipping is a socia…
> Crapping something out as quickly as possible and leaving somebody else to deal with the fallout of a bad data model and violent on-call isn't something to be rewarded IMO.
Sadly you've described precisely the optimal engineering strategy for promotion at my FAANG
Re: You have to know how to drive the car
#6Correction..how dysfunctional companies work..
Re: You have to know how to drive the car
#7The more I read these kinds of things, the more I agree with
> The only way to truly opt out of big-company organizational politics is to avoid working at big companies altogether.
I've done plenty of really fun, engaging and interesting work in smaller companies. If you're able to be involved in open source work, what you do can still be something that many people appreciate, beyond the customers of your company,
Re: You have to know how to drive the car
#8> You ought to know that crushing JIRA tickets is rarely a path to promotion (at least above mid-level), that glue work can be a trap, that you will be judged on the results of your projects, and therefore getting good at shipping projects is the path to career success. Notice that the author didn't write "getting good at delivering value." They wrote "getting good at shipping projects " because > Shipping is a socia…
> Crapping something out as quickly as possible and leaving others to deal with the fallout of a bad data model and chaotic on-call isn't something to be rewarded but it's how many companies seem to work.
Engineers who do this leave nothing but ashes in their wake even if they keep getting promoted for it.
Re: You have to know how to drive the car
#9Do you ever get tired of playing this “visibility,” “impact,” “promo politics” game and think, “I came into this industry because I like computers, not… whatever this is”?
Re: You have to know how to drive the car
#10glue work is real work and a lot of projects get stalled or blocked because there was no glue; especially in SOA where you have different teams with differing roadmaps integrating with each other. It's not just about communication/socialization, but also how code interacts and how the contract is defined.