Earlier quoted context omitted.
A solo tech explore is not leading a project.
Forget leading a project, he completed most of it.
I didn’t say you couldn’t write a lot of code remotely.
You don't want to hire "the best engineers"
301–310 of 326 posts
Re: You don't want to hire "the best engineers"
#302Earlier quoted context omitted.
Forget leading a project, he completed most of it.
I didn’t say you couldn’t write a lot of code remotely.
I guess it depends on what you mean by “building a new CPU architecture.” Granted, porting an existing one to another existing one isn’t the same thing, but it’s as momentous an accomplishment, no?
Re: You don't want to hire "the best engineers"
#303Earlier quoted context omitted.
Why ever hire mediocre talent?
Because you're solving mediocre problems for terrible pay. If you want to solve the world's toughest problems for terrible pay and can meet the bar, there are other places with a very happy customer, stable careers, and great benefits.
In my experience, that is what contractors are for; grind through the blergh B and C tier tickets. You can have onshore developers do that but a lot of companies seem fine with offshoring those tasks.
Re: You don't want to hire "the best engineers"
#304Earlier quoted context omitted.
How did those senior engineers assign and track work to less senior devs in the team in your case out of curiosity?
Depends - sometimes with simple Jira boards, sometimes with other tools like Smartsheets or Air Table or a simple spreadsheet, sometimes with post-its and a white board, sometimes with no system formal or otherwise. My point is less about Jira specifically and more about tool/process dogma (although I do think Jira is the tool of choice for most “we must used the Agile Toolkit Scaled Enterprise Framework Productivity…
Fair enough, thank you!
Re: You don't want to hire "the best engineers"
#305Earlier quoted context omitted.
How did those senior engineers assign and track work to less senior devs in the team in your case out of curiosity?
One way is for senior engineers to give junior folks well-defined areas of responsibility, and then not worry about assigning and tracking small tasks within that. The more senior folks explain and motivate what we need and talk through what the interfaces around the area are and how it fits into the broader work of the team, then help as-needed. Instead of trying to "track" work in terms of tasks, you keep up with t…
This sounds really interesting, I bet it’s tuned to work really well for many engineering problems. I can imagine however that for certain company structures it would be a difficult fit.
Re: You don't want to hire "the best engineers"
#306Earlier quoted context omitted.
You're missing the most important kind of great engineer: the guy who's got adequate technical skills but fantastic executive functioning skills. A lot of bright engineers target the "fun" problem or will otherwise get distracted, leaving a lot of simpler tasks ignored. Every team needs the dev who opens up Jira, opens a sorted list of tickets, and just knocks them down one by one, all day every day. Without them, th…
I know that guy, he’s me. Gotten me further than some brilliant but eccentric developers I know.
God bless you. I'm not one of y'all, but if I ever started a company, you'd be hire #1.
Re: You don't want to hire "the best engineers"
#307Earlier quoted context omitted.
JIRA is so dysfunctional in many places that people do a good chunk of intra-team planning in spreadsheets and docs instead, and use JIRA sparingly to make everyone faster. I saw this effect live at my previous big tech after they moved to JIRA. JIRA got used way less than Phabricator because of all the friction it introduced and a lot more informal google docs + slack bot usage increased instead. I remember to this…
I think the core error is marrying a communication tool for the people doing the work, to a reporting tool for people who aren’t doing the work. Managers are all about that kind of automatic hyper-legibility (I’m skeptical about that being worth anything like the investment most companies put into it to begin with, but that’s another topic) but all it does is shove important communication into side-channels and make…
As a side note, as a developer I’ve never understood why other devs find updating tasks so hard. It’s super easy and makes you look good, and if I’d worked hard and not updated the ticket I can imagine that from my managers perspective it looks like I haven’t done much, that’s bad for me and I would get anxious and not want that. Should be simple, right?
Re: You don't want to hire "the best engineers"
#308Earlier quoted context omitted.
Good leaders are great communicators and if they don't write anything down I wouldn't consider putting them up as either.
JIRA is so dysfunctional in many places that people do a good chunk of intra-team planning in spreadsheets and docs instead, and use JIRA sparingly to make everyone faster. I saw this effect live at my previous big tech after they moved to JIRA. JIRA got used way less than Phabricator because of all the friction it introduced and a lot more informal google docs + slack bot usage increased instead. I remember to this…
It depends strongly on how it’s used. If you just use it for specific things it’s fine, trying to do everything in JIRA sounds like a terrible idea so why would anyone do that
Re: You don't want to hire "the best engineers"
#309Earlier quoted context omitted.
Ironic considering Netflix content is mostly F-level junk these days.
Not really. The quality of engineering has little to do with the quality of content. Their problem is that the quality of engineering started off being critical (who cares how good the content is if you get endless streaming failures?) and is now not so important.
Maybe an investment in "A-players" for streaming stifled cultural diversity and kept engineers from being able to innovate on novel media formats where they are losing engagement of the younger demographic to TikTok and other social media video formats.
The same corporate strategy and culture that hired "A-player" engineers for streaming is hiring "A-player" studios for content.
Defining A-players as such means you've set the rules of the game instead of building a culture of adaptive success criteria to meet customer opportunities. The label itself is a function of organizational ossification. This is the likely legacy of our tech giants; innovative in only one direction and not able to change fast enough to avoid becoming a brittle, mediocre institution over time.
As consumers, we can all feel this ossified mediocrity every day.
Re: You don't want to hire "the best engineers"
#310There is no such thing as "the best engineers." Some engineers are definitely better than others, but once you pass the bar of "really smart, great work ethic," the tech tree diverges pretty dramatically. Some engineers (like Notch) are amazing at quickly putting out vast quantities of mediocre code, prototyping ideas, maintaining a clear product vision, and bringing something into reality quickly. Other engineers (l…
You're missing the most important kind of great engineer: the guy who's got adequate technical skills but fantastic executive functioning skills. A lot of bright engineers target the "fun" problem or will otherwise get distracted, leaving a lot of simpler tasks ignored. Every team needs the dev who opens up Jira, opens a sorted list of tickets, and just knocks them down one by one, all day every day. Without them, th…
Guy?