Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to be a -10x Engineer

taylor.town

Post reply on HN
Print view View original

271–280 of 514 posts

Re: How to be a -10x Engineer

#271

Post by CTmystery »

> To inconspicuously waste others’ time, write lengthy messages/documents and share as widely as possible.

I transitioned from startups (for 10 years) to a large company (for 5 years). Part of that move was adjusting from a culture of no lengthy documents to a culture full of lengthy documents, and I would never want to go back. Having explicit documentation in writing, where folks can debate the merit of ideas is so so much better than having it living in a few people's heads, unable to be critiqued.

Edit: add a word.

Re: How to be a -10x Engineer

#272

Post by Xelynega »

vbezhenar wrote: post #252
whateveracct wrote: post #179

Earlier quoted context omitted.

Yep I've seen seniors/principals come in and steamroll people trying to do FP by claiming that it was inscrutable and irresponsible. Sometimes even going up the chain to cause shake-up without the team's input. Even though said FP was in production, working with a low bug rate, and the entire team was fine with it. And I've seen this happen at multiple companies. I've come to think it's the biggest existential risk t…

I am that guy. Because you’ll leave and there will be no one brave enough to support and expand this code. And so it’ll get rewritten from the scratch. Why not write it in a maintainable way from the start. A significant part of choosing a technology is economics of people available to hire. Who can work with that technology 5 years later, when original authors will be long gone.

Isn't that kind of self-fulfilling?

Only choose technologies that are popular for production stacks -> more people using those technologies professionally(implying less using others) -> only choose popular technologies -> etc.

From a "making a quality product" standpoint it would make more sense to me to choose the technology intelligently according to the needs of the product. Anything less is just a business mythology about trying to deliver a lower quality product for a lower cost.

Re: How to be a -10x Engineer

#273

Post by knsv »

danaris wrote: post #265
denton-scratch wrote: post #200

Earlier quoted context omitted.

> Common examples include presentations, diagrams, and ticket management. Ticket management is stuff that needs doing, obviously. Diagrams are illustrations; if something is so complicated it can only be understood with a picture, it's too complicated. But a quick diagram on a whiteboard (or with a pencil on the back of a fag packet) might be helpful. Presentations (with slide-decks) are for managers[0], not engineer…

> if something is so complicated it can only be understood with a picture, it's too complicated Absolutes like this contribute significantly, depending on the perspective they're spoken from, to the anti-intellectualism in our society today, or to a culture of elitism. For the first, some things are complex, and that complexity is part of the real-life systems and structures they have to interface with or represent.…

I find that I write most diagrams for myself as a reader. It takes much less time to get an overview some logic I have not touched in a while when there is a diagram to start with. Once I remember the big picture I dig deeper via the code.

Re: How to be a -10x Engineer

#274

Post by 2OEH8eoCRo0 »

lispisok wrote: post #270

sigh . The 10x engineer has become tech's most toxic concepts and devs are its victims, yet we keep bringing it up constantly. Every time it's brought up it's a new variation that's either bad or good but always different than the original proposal of the BEST programmers are 10x more productive than the WORST developers from a paper in 1968. All that is come of it is devs arguing about a hypothetical programmer is a…

I thought so until I met one. He knew what our team lead wanted before he wanted it and would already have it done, along with all of his assigned work. He would take initiative and build tools that the whole team could use and be more effective with. He had a huge impact on me.

Re: How to be a -10x Engineer

#275

Post by jameshart »

swiftcoder wrote: post #178
jameshart wrote: post #149

Earlier quoted context omitted.

I understand developers’ complaints about this sort of thing and I am as much of a Jira-burnout victim as the next coder. But. How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one? 15% honestly doesn’t sound like a number I would automatically assume is ‘too much’ for such activity. I’m not sure even 30% sounds like a crazy high number. Bu…

> Figuring out if the plan is still the right one? 15% every week is the problem here. If you spend 10% of your annual budget on upfront planning and 5% monthly on checkins, that's maybe ok. Putting the whole team in a room every week is just going to churn the plan constantly - inputs likely aren't changing with that frequency, and you aren't going to be able to pull in all the other stakeholders that often anyway

Sorry, are you suggesting a better way to operate is to have the team go off for like a five week offsite to come up with a plan for the rest of the year? Then once a month, they get a day to figure out if the plan’s still working?

It’s an option, I guess… let us know how it works out for you.

Re: How to be a -10x Engineer

#276

Post by polalavik »

flumpcakes wrote: post #40

> Ask your team to perform tasks that resemble work. Common examples include presentations, diagrams, and ticket management. I'm as salty as the next guy, but in my experience it has been the sub-par employees who are the ones that don't do this. Ticket management is not busy work, it's a necessity for everyone to keep updated. Presentations and diagrams are tools to communicate. I can safely say that by far the most…

I don’t know. Tickets can still be busy work depending on when you demand them to be done. Sometimes a ticket might best be handled at a different stage in the project to give it the time and context it deserves. If you are just closing out tickets, sometimes out of context and as fast as possible, you are doing busy work.

This could just be bad ticket management with where I work. Or we use tickets in a less standard way. I’m not sure, I work in fpga design so it’s not like a user submitted bug, it’s a request from one of the 1000 review meetings.

Re: How to be a -10x Engineer

#277

Post by ryandrake »

JoeAltmaier wrote: post #250
robertlagrant wrote: post #233

Earlier quoted context omitted.

What's a priority but a way to decide what to do next? The fact it's stored as a label on a ticket doesn't seem particularly relevant.

Absolute priority quickly becomes washed out - everything gets shoved to one end of the range. A useful priority scheme might be, insert the ticket in the list of open tickets by urgency and importance. Something like that, that you can actually make arguments about and compare.

Almost every software company I've ever worked with had this insidious "priority inflation" that couldn't be stopped. It works like this:

We start out with some sensible definition of priority for bugs: P3 = nice-to-have, P2 = low-priority-but-ship-blocking, P1 = emergency-fix-this-now. Bug intake goes on for a while under this system. Some bug filers don't feel their P3 or P2 bugs are getting worked on, so they "promote" those bugs to P2 and P1. That'll show those engineers my bug is important! Now we seem to have more and more P1 emergencies going on, and the team is struggling to just get through those. Nobody knows which ones are actual emergencies, and which ones are just "somebody being passionate about a bug".

Soon, we get an actual pants-on-fire production emergency. This emergency is more urgent than any P1, so we call it P0! Now we finally have a way to mark real emergencies, because the bug database is now overflowing with P1s. Soon people realize they can deem their favorite bugs as really-really-important, so they promote them to P0. Eventually, the database is now overflowing with P0s, and nobody knows what's really urgent. Then another real pants-on-fire production emergency happens...

Re: How to be a -10x Engineer

#278

Post by ejb999 »

Ensorceled wrote: post #167
ejb999 wrote: post #58

Earlier quoted context omitted.

>>Explain code in private messages. ...and this is the natural result of the 'no comments allowed in the code' nazi's that seem to permeate lots of organizations. For the life of me I could never understand that particular bandwagon. I for one love it when I go back into my code after a few years and a few well placed comments remind me why I did what I did last time I worked on it.

I took over leadership of a project where the previous CTO was a "code should be self documenting" proponent and enforced a comment limit with a precommit hook. I think I made some of the developers cry when I asked why there were so few comments.

even worse, I worked on a project where you were not allowed to have comments in code, but if you really felt a need to explain something, you could put it in the projects readme.md, referencing the file and line number and why you did what you did.

Talk about a bone-headed outcome of claiming 'we don't allow comments in our code' mentality.

Re: How to be a -10x Engineer

#279

Post by steveBK123 »

jameshart wrote: post #275
swiftcoder wrote: post #178

Earlier quoted context omitted.

> Figuring out if the plan is still the right one? 15% every week is the problem here. If you spend 10% of your annual budget on upfront planning and 5% monthly on checkins, that's maybe ok. Putting the whole team in a room every week is just going to churn the plan constantly - inputs likely aren't changing with that frequency, and you aren't going to be able to pull in all the other stakeholders that often anyway

Sorry, are you suggesting a better way to operate is to have the team go off for like a five week offsite to come up with a plan for the rest of the year? Then once a month, they get a day to figure out if the plan’s still working? It’s an option, I guess… let us know how it works out for you.

That's a horrible idea for sure, but I'm not sure the current model being derided works for all team compositions either.

In a 20+ person dev team with a lot of juniors, the team is not "coming up with a plan" or "deciding if its still working" so much as product/tech lead/a couple seniors who have zones of responsibility are handing one down. The two hours spent in the room is agile kayfabe.

"Get everyone in a room and hash it out for 2 hours" is maybe a model that works at team size of 5, senior, empowered engineers, but it is not something that works at large scales.

Post reply on HN