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

Some reasons to work on productivity and velocity

danluu.com

Post reply on HN
Print view View original

91–100 of 183 posts

Re: Some reasons to work on productivity and velocity

#91

Post by sureglymop »

cuddlecake wrote: post #71
vymague wrote: post #67

I was going to ask how to identify the "hotspots". But I guess, for most people, the mentioned learn how to touch-type fast and editor shortcuts are good enough first steps. And of course there's the obvious improve your programming knowledge and skills. One of the linked HN https://news.ycombinator.com/item?id=22253893 post has an interesting advice. Record yourself when you're coding. Watch them and identify possib…

Recording oneself is also a common strategy for improving musicianship. When I was drumming, it sometimes helped me see exactly where my movements where improper, hesitant, or superfluous/exaggerated. When I look over junior developers' shoulders while they code, i kind of do something similar, where I point out small improvements in their "movement from one state of code to another", like IDE functions for refactori…

That honestly sounds exhausting.. like, just thinking about it, what if they have set their own keyboard shortcuts? I feel like ones "workstation" or "setup" is always too individual (and that's good). Who are you to know that they don't know about a certain editor feature and just don't like to use that in their workflow?

And why does one even need to know vim at this point in time? Don't get me wrong, i know and use vim daily but does it differentiate me in any way from someone who uses nano or micro or whatever editor they have in their workflow? Not at all.

Re: Some reasons to work on productivity and velocity

#92

Post by m0zg »

spaetzleesser wrote: post #86
m0zg wrote: post #54

Earlier quoted context omitted.

Try actually tracking the time using a free service like Harvest. You'll be surprised just how much longer some things take objectively than subjectively. I'm not saying do retrospectives every week or whatever, but do at least a few, then take note of time sinks and weigh their utility against the time they take. I don't think one can build awareness of this without measurement, something the essay also alludes to.

I have done this but management can’t accept that the mandatory overhead is taking that much time. They just don’t want to hear it.

It is still useful for you to know. That "overhead" often does very little to advance your career or even just advance _you_ professionally. And until you measure how much overhead you're incurring, you wouldn't even know.

Much like how people didn't know they're spending 4+ hours on Instagram and YouTube every day until Apple started cataloging and surfacing phone usage. When I saw my own usage I was horrified, and I have cut it down significantly since then, and closed FB and Instagram accounts entirely.

To translate that into the professional domain, there may be some optional bullshit activities you participate in solely because you don't see their cost. You'd be able to identify them and cut down on your participation, possibly either improving your career situation, or improving work/life balance, or both.

There was a time when I worked at a BigCo where there was so much bullshit during the day, I only could do work from home in the evenings. So I worked ~14 hours a day for years - 8 hours spent on bullshit, then another 6 at home on actual work. That wasn't fun at all.

Re: Some reasons to work on productivity and velocity

#93

Post by zaptheimpaler »

hardwaregeek wrote: post #31

I suspect the dissenters and Dan are not as far apart as one would expect. What I see in the dissent is a rejection of the specific brand of Silicon Valley rah rah productivity cult. There's a lot of mysticism in SV style productivity, whether it's the new hottest app or the latest lifestyle craze. It's also almost always directed at squeezing more work out of someone who's already working far too much. What Dan's pr…

Very well put. This was sort of my attitude to programming years ago - to try to get really good at the craft. But the question is, is that going to be rewarded or recognized at all? Who makes more, the programmer dedicated to their craft and domain getting better every day, or the leetcode expert who jumps from one FAANG to another getting 30% raises each time? What is the track for promotion at most companies - being a better programmer or learning project management and becoming a manager/lead who only spends 10% of their day coding?

I could try to get really good at programming. I could try to really learn something like databases or systems programming extremely well. But is a recruiter looking at my resume going to see that? Is a management chain that doesn’t really understand software going to reward that? Does the 100th startup building your average webapp need that skillset at all? Does your manager even look at a pull request and have any idea of the quality of your code, or do they simply evaluate # tickets / day?

I have never worked at a FAANG or any of these beautiful environments with amazing people dedicated to the craft of engineering. I have worked in places where great engineering is not recognized, or (more often) just not as important as okay engineering + project management + communication + being friends with the right people. The job of a modern software developer in most places is only partly about programming. Pure programmers are just low value cogs in an assembly line, and being a great programmer only makes you a slightly better low value cog because it won’t be recognized. Your average manager sees you do the task in X days and assumes it was about X days worth of work - they have 0 idea if it would’ve taken someone else 5X the time. Its a luxury to work somewhere where your job really is just engineering and good engineering is recognized and rewarded. When your chances of working somewhere like that are low and you have limited time, maybe its not worth investing time and energy into leveling up as an engineer.

Re: Some reasons to work on productivity and velocity

#94

Post by personjerry »

es7 wrote: post #15
jdlshore wrote: post #8

The problem I have with discussions about “productivity” (including 10x engineer chest-beating) is that no one ever defines what they mean by the word. Is it lots of lines of code? Is it clean design and architecture that’s easy to maintain and extend? Responding quickly to business needs? Making a lot of money in a short time? Too often, people arbitrarily choose what they’re good at, or what someone else they admir…

Productivity: If you need an X, how quickly can you implement an X at a high level of quality? If your product manager asks for a new widget or api, can you implement it without any major bugs in 1 hour? Or will you take three days because you don't understand your programming language, your codebase and your requirements? Will the widget/api be free of major bugs, or will it fail on a variety of edge cases that coul…

> If you need an X, how quickly can you implement an X at a high level of quality?

That's the wrong question for anyone who's not a new grad junior engineer. If these are the only kinds of question you're addressing, you're probably replaceable by a Ukrainian dev shop.

In reality depending on your particular role and organization the questions you need to answer range from "How do I find product-market fit" at an early-stage startup to "How do I meet my client's requirements" to "How do I move the needle on X metrics" at a big company.

The key difference between these kinds of questions is that there can be many different routes, and measuring "productivity" in one metric limits the ability to explore. For example, "How fast can you implement a chat widget" doesn't allow for the exploration of alternative ways to engage with customers -- emailing them directly might've been much better.

Even assuming you are very "focused" on pure engineering, measuring the speed of implementing X doesn't account for "productivity" on a personal level, i.e. perhaps you built it in 5 days but now you're burnt out for the next month. Or you had other projects you didn't end up working on. Or you neglected your family. By the way, you handwaved over "X level of quality" but I'm sure we all know that this in itself is nontrivial to gauge.

There are many goals that may count as "productivity", and you don't necessarily even know all of them. Therefore its quantification is nontrivial.

Re: Some reasons to work on productivity and velocity

#95

Post by chousuke »

handrous wrote: post #51
agumonkey wrote: post #37

Earlier quoted context omitted.

after doing a few kinds of jobs: - food retail: producing hundreds of sandwiches an serving hundreds of customers back to back, teaches you about productivity - landwork: 8000 picks per day teaches you about work maybe i'm masochistic, but whenever I see people relaxed at work, neither doing much nor thinking much, I consider it's not work. There's no difference between what they do and me at home chilling.

I've done tough physical labor, and repetitive physical labor. They may wear out the body (or may invigorate it, depending on the load), but the mind is fresh even after 8+ hours, in my experience. And it feels good . After six hours of typey-typey in front of a screen I feel used up . Worthless. Dead. And that's a very good day—four is more typical for "how long can I do computer work before I just want to curl up a…

I think when you begin to work on something, there's the phase where you are "stuck" and need understand the problem well enough to generate an acceptable initial idea to get started. To me, this is the draining part. However, once I have that understanding and can start exploring it, I can easily work for hours; it still requires mental energy and is still draining if I go overboard and don't stop in time, but it's not the soul-crushing kind that being stuck on a problem can be.

Re: Some reasons to work on productivity and velocity

#96

Post by chousuke »

sureglymop wrote: post #91
cuddlecake wrote: post #71

Earlier quoted context omitted.

Recording oneself is also a common strategy for improving musicianship. When I was drumming, it sometimes helped me see exactly where my movements where improper, hesitant, or superfluous/exaggerated. When I look over junior developers' shoulders while they code, i kind of do something similar, where I point out small improvements in their "movement from one state of code to another", like IDE functions for refactori…

That honestly sounds exhausting.. like, just thinking about it, what if they have set their own keyboard shortcuts? I feel like ones "workstation" or "setup" is always too individual (and that's good). Who are you to know that they don't know about a certain editor feature and just don't like to use that in their workflow? And why does one even need to know vim at this point in time? Don't get me wrong, i know and us…

What does it hurt to tell someone about a feature they could be using, especially if you're mentoring? If they don't want to, they'll tell you and that's fine, but they need to be aware of it in the first place to make that choice, and the assumption that other people know the same things as you is often wrong.

Re: Some reasons to work on productivity and velocity

#97

Post by Jensson »

porknubbins wrote: post #68
Jensson wrote: post #39

Earlier quoted context omitted.

> Too many people are extremely static in their assessment of their skills. They make overarching claims like "oh I'm just not good at cooking" or "I just can't type very fast", when they can remedy these issues with practice. The people with the biggest blockers are those who argue along the lines of "learning skill X isn't even important, no learning skill X actually makes you worse!". That is the perspective so ma…

I wish I could identify a finite set of tasks at which to practice and get much faster. The tradeoff between getting faster at one thing and learning a new thing that could potentially improve my productivity even more is never really clear to me. Someone can have perfected their craft in X and then something better comes along and replaces the whole paradigm.

Master the basic building blocks of programming. Frameworks comes and go but the basics are the same. Master as in "I do X correct the first time even without thinking" not "I know how X works". The "do without thinking" is when your subconscious is doing it for you so your conscious doesn't have to. You want to put as much as your work there as possible, it is like putting work on a GPU instead of your CPU, so every reusable programming trick and pattern should be there. This also helps you reason about code since now your sub consciousness can build code on its own and therefore help you reason in much larger chunks.

A person who hasn't mastered loops and conditionals will fail FizzBuzz. That is bad, you recognise that I hope. But it doesn't end there, you can master so many more powerful parts of programming and get as fast as you were at FizzBuzz att many other much more complicated tasks as well. Ultimately programming takes time due to all the parts you didn't master, but when you have mastered enough parts then you can fit just about any problem into parts you have mastered and code them up extremely quickly.

So the speedup you see is roughly the speedup you saw from at first struggling a lot with loops and conditionals early on when learning programming, to today when you do them effortlessly and instantly. Now the other things to master aren't as simple patterns as loops or conditionals, but the end result is the same improvement in speedup and effort.

For example, competitive programming is about mastering a ton of such chunks. You don't memorize solutions to get fast, you master thousands of such chunks and compose them to solve problems in 5 minutes that would take regular programmers 5 hours if they can solve it at all. I went that route and it is similar to how people master chess, a grandmaster makes better moves after a few seconds of thinking than a typical chess player who has played for years thinking for many minutes.

It took about a year and then I could solve hard problems at similar pace as the best in the world with basically no errors, compare that with spending 4 years in college, I think the practice is worth it, I have never needed to practice that again as the chunks I mastered doesn't go away, it is like learning how to ride a bike. You forget the details, but your subconscious wont forget those chunks. Of course I can't solve hard competitive programming problems in 5 minutes today, but I can solve most leetcode "hard" problems I haven't seen before in under 15 minutes and basically all of them in under 30 even though I haven't practiced these things for many years.

Now, this wont solve all your programming woes, you still need to understand requirements, talk to customers, learn API's etc. But at least you are no longer bottle necked by composing programs. Instead you can throw together MVP's quickly, show prototypes to make discussions more fruitful etc. Also most jobs doesn't requires this level of mastery, only do it if you aim to join top teams using your technical skills if you really get good at this then many teams that wouldn't care about you before now gets very interested in you since so few are this fast, or if you want to build your own products on your own, or if you find mastering things fun.

Edit: Sorry for edits, but here is last bit. When I worked at a high performing team at Google I averaged over 500 lines of code a day going through code review and running in production when I wasn't constrained on non-programming bits like understanding the problem etc. To do that you write 10 changes, each about 50 lines and trivial to review since everything is super clean, otherwise you can't get through code reviews fast enough. Code reviews, unit tests, fixing edge cases etc, none of that are excuses for being slow. Now it is still fine to be slow, I don't blame people, I'm just saying it is possible to be fast if you deliberately practice a lot to be fast.

Re: Some reasons to work on productivity and velocity

#98

Post by friedman23 »

Rapzid wrote: post #74
friedman23 wrote: post #22

Earlier quoted context omitted.

I used to be amazed wondering how people claimed to work 12 hours a day until I realized they consider writing emails and talking to people on the phone work (which it is). But of course me being a software engineer I imagined for some reason when they said work they meant something like coding which after 6 hours has me drained.

How much sleep do you get?

My problem isn't sleep, my problem is skipping meals which screws with my energy. I always get at least 8 hours of sleep.

Re: Some reasons to work on productivity and velocity

#99

Post by rhapsodic »

rsj_hn wrote: post #82
crate_barre wrote: post #80

Earlier quoted context omitted.

I’m fascinated by who is downvoting you without an explanation.

I don't think you're allowed to reply to a comment and also downvote it. Suffice it to say, the comment is not rooted in any reality of what Silicon Valley was like, it is pure uninformed speculation, salted with a heavy dose of facile anti-capitalist talking points. It's lazy and factually incorrect. First, things weren't that fast in the past. They were more fast relative to the old system of being employed for lif…

> I don't think you're allowed to reply to a comment and also downvote it.

Not true. Now I will remove the down vote I just gave you to test your claim.

Re: Some reasons to work on productivity and velocity

#100

Post by waterhouse »

rsj_hn wrote: post #82
crate_barre wrote: post #80

Earlier quoted context omitted.

I’m fascinated by who is downvoting you without an explanation.

I don't think you're allowed to reply to a comment and also downvote it. Suffice it to say, the comment is not rooted in any reality of what Silicon Valley was like, it is pure uninformed speculation, salted with a heavy dose of facile anti-capitalist talking points. It's lazy and factually incorrect. First, things weren't that fast in the past. They were more fast relative to the old system of being employed for lif…

> I don't think you're allowed to reply to a comment and also downvote it.

Close. You're not allowed to downvote a comment that is a reply to your comment. (Or a comment >24hrs old, or if your karma < 500 (IIRC).)

Post reply on HN