Hacker News Reader

Comment by futureshock | Hacker News Reader

I think the true 10x multiplier is not a technical skill at all. It is the ability to quickly cut through irrelevant tasks and actions to focus on the thing that will move the business goal forward fastest. It is enshrined in the concept of the MVP and the short iteration cycle. Quicky building something that does not solve a business problem is not productive. Work=force*displacement. No movement, no work.

A closely related skill is the ability to cut through all the abstractions and interfaces to get to the root cause of what is broken or needs changed. A technical and organizational debt buster if you will.

View on HN

Absolutely this. I was a chronic procrastinator prone to intense anxiety and breakdowns just before deadlines. Then I took a really good ~3 hour course on time management, and it seriously changed my life. I can’t even describe how much more productive I am. It’s changed how I approach every task, professional and personal. I can’t even remember the last time I felt any sort of stress or anxiety about my to-do list. A big part of it is figuring out what doesn’t have to be done right now (“positive procrastination”).

Edit to add that the course was “Time Management Fundamentals (2016)” by Dave Crenshaw. I completed it on LinkedIn learning. For those of you who’d like to give it a try, my advice is: do all the exercises. You won’t get the full value out of the course unless you actively incorporate the whole routine into your workflow. There’s a learning curve, but it’s absolutely worth it. Also be warned that the presenter’s personality is a little off-putting (to me, anyway), but he absolutely knows what he’s talking about, so listen to him.

Can you share this resource?

Sorry about that—edited the original comment to include more info :)

I'm also interested in what you learned and which class you took!

What course was this, may I ask?

I might watch it ... later :p

Curious what course you took and if you have time, a summary of the most valuable skills you learned?

Could you share any tips or the name of the course?

Sorry about that—edited the original comment to include more info :)

I'd like to second the recommendation for Dave Crenshaw's courses. I never realized before that I wasn't actually managing my time; I was just desperately chasing the non-existent end of my entire life's to-do lists. I'm still working on getting through my initial in-box (the one you create by going through his trigger lists), but all the important stuff got done, and I have confidence that the things I haven't gotten to yet aren't important enough for me to panic about (otherwise I would have done them!).

The "time management tips" one is a kind agglomeration of his advice on managing your time, your relationships, your reports, etc., and is a good follow-up. He has a course on having productive meetings, as well, which is well worth the time. It may make you hate meetings at your work, though XD.

Honestly his courses provided a lot of relief and validation to me, as well as hope for a future working in companies. I can't recommend them enough.

Thanks for the other course recommendations! Given how insanely valuable his time management course was for me, I’m absolutely going to jump on that “productive meetings” course.

I started going through the course three days ago, right after you posted it. I can already feel improvements in organizing my time.

The course doesn't offer anything novel - for example it has elements of Getting Things Done. But it's presented in a more accessible way that resonates with me. It also focuses on making good habits, something I already discovered in another book recommended on HN, Tiny Habits.

Thanks for the recommendation. I really appreciate it.

This. Which isn't to say that technical knowledge doesn't matter, it truly does. But, the primary problem in the industry right now is that the majority of finished code generated by professionals goes unused. The amount of waste is staggering. Working on the right thing is way more than a 10x multiplier.

> The amount of waste is staggering. Working on the right thing is way more than a 10x multiplier.

How much of that waste would you attribute to 1x programmers and how much would you attribute to 0x managers?

I would attribute most of it to poor customer development or product management. If you can’t find the demand for your product, it doesn’t matter how good the engineers or managers are.

Failed projects are inevitable though, even if you do everything well. Good teams don’t look for people to blame, which results in no one sticking their neck out to advocate for stuff. Instead they look to learn from each experience and hone their processes.

85% in favor of managers being the problem. I pulled that number from the Ford Motor Company turnaround where Deming said management was 85% of the problem.

And I mean, who is responsible for curating those 1x engineers in the first place?

And it's not only about features that go unused, but also features that are used but only in support of workflows that improves nobody's life. Or functionality that's used but is a wildly inefficient version of what could have been.

I’m curious about what you’d consider concrete examples of these inefficient solutions? The biggest thing that comes to my mind are SPAs that don’t need to be SPAs.

One example from my employment history was a customer that kept asking for (and unfortunately getting) one special reporting feature after another in a data processing system.

After a couple of years and several such reporting options someone asked, "Can't we just generate a spreadsheet and then your business analysts can do whatever reports they want from that?" and the customer responded, "You can do that?! That would be so much easier for us."

Imagine the weeks or even months of human life (both implementing but also using the less efficient reports) that could have been saved if the right solution had been implemented from the start.

That's literally time taken out of someone's life that they could have used to be with family or whatever they wanted instead of transcribing ridiculous reports.

(Of course, those reports were probably only generated to be looked at once in some recurring management meeting, only for the executives to feel good about having seen data. I don't think the reports were ever used to support any decision.

This means the entire reporting theatre was completely bullshit and the customer could have paid the business analysts to sip drinks on the beach instead with no loss of productivity. But that's just my cynical view.)

> That's literally time taken out of someone's life that they could have used to be with family or whatever they wanted instead of transcribing ridiculous reports.

Only if the product is run by one or two people who give each other that much time off. *Much* more likely, this work not commissioned by the client, leaving space for other work to be done.

This "automation will lead to more free time" is a utter utter myth, because those with the power to pay staff will just sell their staff's time+skills to someone else/some other problem.

You're right, of course. In practise, the organisation would likely make up some other bullshit work to fill up the time, because God forbid people get to enjoy life!

(There's a tiny chance the void would be filled with useful work, and that's also a good outcome in my book.)

> The biggest thing that comes to my mind are SPAs that don’t need to be SPAs.

These are unlikely to be technical issues, and more people/process issues. SPAs are popular because they optimsie for developer productivity (so arguably the opposite). Others have talked about them, but examples like focusing on the wrong problems to solve (if you're a startup making a video game, do you really need to build your own chat app? [0])

[0] https://nira.com/slack-history/

> the majority of finished code generated by professionals goes unused

What are you referring to?

I'm referring to how companies ignore the thorny problem of what to build and instead focus on getting "Something done", which results in delivery of product increment that users at best say "meh" to, and don't use.

As an aside, from a developers perspective, all of the work is clearly valuable, I mean they got paid 300k+. But from a true definition of value perspective, the change increment is just not valuable to the users as evidenced by the lack of use.

    Value:  Reliable fulfillment of needs

> from a developers perspective, all of the work is clearly valuable, I mean they got paid 300k+

Midwestern US salary caps are more like $90k-$150k.

Yes! I often tell people this in interviews and they act like I don’t have enough technical knowledge. The cult of Leetcode has made this so much worse.

You rarely, if ever, need Leetcode. What you need is to understand deeply what you should be building so you don’t waste everyone’s time!

Part of the issue is that they often don't want you to decide what to build. They've separated out the "building" from the "deciding what to build", so hearing from a candidate that it's important to focus on what to do is off-putting to an organization that just wants you to munch through JIRA tickets all day and find technical solutions to whatever somebody else wants, and then keep a smile on as they change their mind and discard the feature.

100%. Legacy company management finds software engineers who engage in the very relevant question of "what to build" extremely threatening. In my experience they actually treat software engineers who behave that way as disloyal.

As compared to places like tesla/shopify/etc where the Steve Jobs quote rules the roost:

    It doesn't make sense to hire smart people and tell them what to do. We hire smart people so they can tell us what to do.

Amen. or as Peter Drucker puts it (he is dubbed as "the founder of modern management" on Wikipedia) :

"There is nothing so useless as doing efficiently that which should not be done at all."

https://en.wikipedia.org/wiki/Peter_Drucker

And likewise, this theme shows up in Tom DeMarco's classic book Slack, which contrasts "efficiency" (the rate at which an organization is moveing towards some goal) vs "effectiveness" (the ability of the organization to choose and steer towards better goals). An important theme of the book is that an organization running full-tilt (maximum "efficiency") intrinsically reduces/eliminates its needed human "slack" to reflect and iterate towards the correct goals. DeMarco also digs into into the many organizational and management anti-patterns, with supporting research, that harm both effectiveness and efficiency (and just plain human well being...)

“Efficiency is doing things right; effectiveness is doing the right things.”

Damned, I had to search for the author and... it's also from Peter Drucker !

"If you don't know where you are going, it doesn't matter how fast you get there."

nice one as well !

This is the right answer.

The proof is that a good coder spends about 10x as long thinking about it before actually committing any code. In a sentence: Be able to visualize the problem in your head first. The actual code, if it's elegant and succinct, is incidental.

> The proof is that a good coder spends about 10x as long thinking about it before actually committing any code.

This seems antithetical to the post above yours. Or at least how I'm reading it. In bigger tech co's this looks a lot like massive design documents with a dozen reviewers, all giving enormous amounts of time and thought to the idea in the pursuit of "building it right". Design processes that can take weeks or months for what is otherwise an MVP.

I've been thinking about this idea a lot recently. I'm decently new to the big-tech-co space, but it does seem like a huge amount of resourcing goes into design and defense of projects. I wonder what y'all think about someone doing a timeboxed MVP (a sprint or less?) as a way of susing out design, and THEN getting reviewers/etc?

Obviously you have to take security into large consideration when doing things like this - but this is what qa/sandbox environments are for.

A pot of big corps have Hackathon weeks for doing just this. A free-for-all to build something you want and that you think will be helpful to the org from your perspective.

And as soon as those weeks are over everyone goes right back to their previously scheduled work.

Hell, wait till you find out how much time is wasted in Dev/Ops just changing the tooling every year or two, literally tearing down and rebuilding everything you already have in the name of staving off another couple years of technical debt. It's silly.

I'm a bit of a rarity in the modern world (and here in the corporate space that is HN), in that I'm the sole programmer on a bunch of large software projects in production that I also maintain and sysadmin 24/7. The only meetings needed are to understand what the clients want and bitch at them that what they want makes no sense, until they start making sense, and then trust me to build it. If something comes up from a design perspective that I think could go one of several ways, I usually have that thought in the shower and mumble to myself for awhile before framing it in terms they would understand as a series of yes/no choices.

This is generally way more efficient than hiring a team, and I know, because I've tried to hire teams to do it. There's a limit to what one coder like me can do, but it's a lot higher than what 4 people bickering can do. I'd say it's around what 8 bickering people can do.

Design and defense of design, though, is not just about ego. Not if it's done properly. The best design/code people will come to you and say this is why this is the only way to do X and lay out the chain of logic that led them to that conclusion. That's not because they'll be personally hurt if you don't go that direction; it's that they're annoyed they'll have to do extra work to make an inferior product if you don't take their advice. Promote those people.

What happens if you get hit by a bus or just want to take a vacation? I think this is more about your inability to work with other people than it is about you truly being a 4-8x coder.

Well, thanks for the confidence; you did hit the nail on the head. I haven't taken a real vacation in 20 years, although I did live in vans and hostels for 10 of those years. For peace of mind, I maintain a set of PGP files signed and keyed to each of my clients which I flippantly tell them to open "if I get hit by a bus", that contain all the SSH keys and details needed to get to their source files / DBs / webservers, extra code hints and lots of juicy advice for whatever unfortunate developer takes over after my demise. (Including shit like, this software is way too old, rewrite it).

If you saw what I write you'd say I was a 20x coder, but that's just from a youngin's perspective. I've been writing code since 1988. The basic value proposition for my clients is that they know I'll die at some point, but it's way cheaper and more efficient to pay one guy they know will get it done, and take the risk they'll have to scramble for someone else in less than 10 years (at which point they'll likely have to rewrite anyway). Also, the shit I write mostly maintains itself. I'm proud to say that my software in 24/7 production has had no actual crashes in years other than the occasional forced server upgrade. If I died, it would take awhile to notice if they didn't keep asking me for new features.

> I'm a bit of a rarity in the modern world

I'll say. It does not sound like you'd be very fun to work with, as a teammate or a stakeholder.

I would say analysis paralysis: no. Strategic thinking/designing: yes.

Take the time to distill it down to a powerful but small concept.

The fact that launching any kind of work in production in a big organization makes it even more important to just focus on tiny changes (sometimes a few lines of code) with huge benefits.

You can have bigger changes as proof of concept first, but select, properly design and launch the most important one.

Exactly I'm living proof that seniority comes with the ability to spend more time on problems to understand all the details before committing stuff which no idea how that works.

Nice: Ah, FedEx founder F. Smith just booted himself out of the CEO slot and to just Chair of the BoD.

At one time he was scared of the problem of scheduling the fleet. Yup, if describe the problem in complicated terms, then the scheduling problem gets wildly complicated, e.g., in NP Complete, etc. -- could have a big team working months on just the first version. But he needed answers right away and, to satisfy concerns of some investors on the Board, needed the answers also to apply to the whole, planned company (eventually it grew to something much bigger than the initial plans).

I was in a meeting looking for a solution with several people, and it was all confused. Finally I just announced that I'd solve it.

I was teaching computer science at Georgetown and had 6 weeks to go to the end of the semester. So, I wanted to be done in six weeks. How'd I do that? Sure, just concentrated on what the business actually needed and threw out the rest. So, in six weeks had the software putting out nice schedules.

Our two representatives of BoD member General Dynamics and major investor evaluated the schedule and announced "It's a little tight in a few places but it's flyable.". The BoD was thrilled.

At one point Smith stated that my work "solved the most important problem" facing the company. The 10X, maybe 1000X, difference was essentially just in delivering what the business needed and dropping the rest.

The main thing is to keep the main thing the main thing. --Steve Covey

It is the ability to quickly cut through irrelevant tasks and actions to focus on the thing that will move the business goal forward fastest.

"Landing the plane" as they sometimes say.

Reply on news.ycombinator.com