621–630 of 783 posts
Earlier quoted context omitted.
"If they can dangle that carrot in front of you and get you to give 110% at your current pay scale for 1-2 more years then why the hell wouldn't they do it?" Cause that's a shitty thing to do. And, as shown, it leads to people leaving.
doesn't matter when there is always a fresh new grad who doesn't know any better waiting to take your place
As a business person, you're going to have to sell yourself/your services to other people. Perhaps that's not too different from pitching yourself to an "anonymous promotions committee"? Interesting and insightful read. Thanks for sharing, and good luck with your future endeavours!
Talking to a customer is (usually) a human process involving an actual conversation. Back-and-forth, incremental, and to the point about business needs of the customer and how you can satisfy them. As a sibling comment said, they have 'skin in the game', they're there to get shit sorted out, they need that shit sorted out and you're there explicitly to help them do it.
Pitching to a promo committee is filling out a form (including fantastic questions like "what's one thing you're good at") where you have no feedback on what the other side is thinking until they tell you 'yay' or 'nay' a month later. Good luck again in half a year. Oh, and those committees will give your packet just a couple of minutes because there's a few hundred of them that they need to handle. Hopefully your packet doesn't get reviewed right before lunch when they're cranky.
Earlier quoted context omitted.
The last time I was interviewed by phone at Amazon, I was asked to write a binary tree to a file. Time given: 30 minutes. Does that count as a puzzle? Did lot's on exercises on binary trees before but was not prepared for that question.
Nah, that sounds pretty simple - you just need to know how to walk a binary tree (basic knowledge) and how to write a string to a file (even more basic knowledge) - provided binary tree stores strings (and with right serializer, everything stores strings). Unless I am missing something. Don't think this qualifies as a puzzle. Puzzle would be something that requires non-trivial knowledge or exceptional insight to solv…
Earlier quoted context omitted.
Nah, that sounds pretty simple - you just need to know how to walk a binary tree (basic knowledge) and how to write a string to a file (even more basic knowledge) - provided binary tree stores strings (and with right serializer, everything stores strings). Unless I am missing something. Don't think this qualifies as a puzzle. Puzzle would be something that requires non-trivial knowledge or exceptional insight to solv…
OK then do it on the phone with the interviewer looking at you as you're typing and your brain has suddenly blanked. I've been coding since I was 9 years old, have a massive (relatively) side project with a couple hundred users, have shipped multiple projects in multiple jobs, and I know what a binary tree is and how to traverse one, but I'll be damned if I can figure out how to do it under those conditions. I absolu…
> I drastically reduced the time developers spent repairing those failures, but there were no metrics that tracked developer time. For several jobs in a row, I've felt that helping others on a team is undervalued and under-recorded. I've been planning to implement the "assist" metric, similar to basketball, on my own team for a while. The idea would be something along the lines of everyone gets a set of assist points…
I worked in a remote team once helping a company in Seattle (that perhaps had a bit of a jock culture problem). I could be stuck for days because following the README in a repo just wasn't enough to get the project to compile and run. Every standup I was telling "I'm completely blocked for the last two days because I cannot run the repo, so I cannot run any tests and at the moment I'm doing absolutely nothing.". To b…
> I drastically reduced the time developers spent repairing those failures, but there were no metrics that tracked developer time. For several jobs in a row, I've felt that helping others on a team is undervalued and under-recorded. I've been planning to implement the "assist" metric, similar to basketball, on my own team for a while. The idea would be something along the lines of everyone gets a set of assist points…
The irony is that Google actually has a separate eng job ladder (Software Engineer, Tools and Infrastructure) which is designed to reward that kind of work specifically. If he had ladder-transferred (a fairly easy process) and gone up before a SETI committee with that same data (peer feedback on stuff like saved development time carries weight that metrics may miss), it probably would have turned out very differently…
If you know ahead of time that you are doing "the dirty work", which usually you don't, do you know how long you are going to do it for, and if it makes sense to apply for a transfer?
Would your manager approve of your ladder transfer if he/she needs to back-fill your position when a good engineer is hard to find or keep to begin with? (Actually, there are scenarios where a manager wants to keep underperformers from transferring out, too)
Lastly, did you really want to be a Tools and Infrastructure engineer to begin with? It started with just being scrappy in order to get the project to a place where you can contribute shiny new features, which everyone is waiting for you to do, yourself included. If you transfer ladders, what are the chances you will be able transfer back in any reasonable amount of time to get credit for doing a good job on what you wanted to work on?
Michael's work situation seems prevalent through a Google-like org, and a ladder transfer is unlikely a realistic solution for that.
> I drastically reduced the time developers spent repairing those failures, but there were no metrics that tracked developer time. For several jobs in a row, I've felt that helping others on a team is undervalued and under-recorded. I've been planning to implement the "assist" metric, similar to basketball, on my own team for a while. The idea would be something along the lines of everyone gets a set of assist points…
The idea would be something along the lines of everyone gets a set of assist points they must distribute to people who help them the most. There is a really great idea in there somewhere - create incentives for helping others - but I'm struggling to come up with a good way to implement it that doesn't just water everything down. The closest I can think of is how repo commits can be counted/graphed per user. Works eas…
Basically it's a thought experiment in which all team members of a project (or group, etc) estimate the impact when losing various members of the team (whose work presumably is done by other team members or contracts) on the final cost.
Run some math on the data and you have a group estimation of the relative contribution of all members.
I have a theory that the reason more managers don't use this available tool is that it would probably rate management contribution on the lower end...
Earlier quoted context omitted.
> What I found most off putting, was when meeting my skip-manager (your managers manager) for the first time during my exit interview, all doors for a senior level promotion were suddenly open, to incentivise me to stay. Doesn't feel great when negotiations with your employer are comparable to those had with your cable provider. Wow, that's one hell of a way to look at things. Thanks for that perspective.
Both are businesses, and most successful businesses are sociopathic. That includes game theory both with customers and internal resources. You are a "human resource", not a friend.
To author: you lost the political game. I busted my ass at a startup for years and also lost the political game. So I'm speaking from experience here. You can either get all mad and worked up and pissed off about it, and waste years of your career (as I did) being pissed off, stubborn, and refusing to change. Or figure out how to play. I'd like to think there are places with better politics but I think it's pretty en…
> You might work for customers, or clients, or whatever, but not "yourself". The difference is, you don't have one boss... So your risk(s) are well diversified (or, at least better than if you're an employee).
Earlier quoted context omitted.
Capability and responsibility become conflated very easily. You start off as the superhero who can fix problems, but that gradually creates dependency. 1st year 'Thanks for your help finding that error that was holding us up.' 2nd year 'We are all finished now. Just sent it over to you for debugging.' 3rd year 'Hey we are all waiting on you to fix. Big deadline for big customer.' CC: management 4th year Management: '…
So... how does one break the cycle?
From an employee standpoint, when helping your peers ask them to take notes. Any additional requests -> ask them to refer to their notes. This sets a clear boundary and gives you a built-in defense while still helping the team achieve goals. Now you are no longer the obstacle, because you provided training. The obstacle is now inability to properly take notes or retain information. knows this and is much more likely to attempt solutions rather than nag you into doing their job, or escalate to management. Additionally will have better knowledge retention by synthesizing their own notes.
Documentation is a good barometer of this behavior (it's the first casualty). If your environment has little documentation, then you are probably looking at a group that will punish responsibility. No one documents anything if all that earns them is 'John's instructions don't work, I've asked him several times to fix it'.