How do you actually deliberately practice and improve programming?
What about data science / research?
Curious if anyone has suggestions.
Some reasons to work on productivity and velocity
151–160 of 183 posts
Re: Some reasons to work on productivity and velocity
#152Earlier quoted context omitted.
Interesting POV. Can you elaborate on an alternative to the way of industry programming? Or more simply, list some of the ways in which industry brand programming is flawed?
Not the poster, but IMO we are craftspeople being made to work like assembly line workers.
I would argue that assembly line workers were once craftspeople.
Craftsmanship still exists, but it’s specialized and focused on products that can demand the higher price.
Is this not the same with software?
CRUD work is almost infinite and demands higher output at the expense of quality.
Contrast that with unique OSS projects, and defining product features.
Re: Some reasons to work on productivity and velocity
#153Earlier quoted context omitted.
Energy constrained? That’s odd. Just eat more? CICO after all. Maybe guzzle some lard? It’s very dense.
"Energy constrained" doesn't mean he lacks sugar, it means his brain isn't letting him do the work anymore because it is in the process of burning out.
Yes, this is my intended meaning. I am a PhD student working on my thesis. After a certain number of hours of doing mathematics or algorithm design, I have to switch to easier tasks like reading papers in a domain I'm familiar with, or documenting code.
While I cannot speak for anyone but myself, my performance on highly challenging tasks is capped at 4-5 hours per day. At that point, it is better for me to switch to lower hanging fruit.
If I am feeling especially inspired, sometimes I'll put in a 12+ hour day of hard work. Rarely, even two or more in a row. But inevitably, I will feel extra burned out in the subsequent days.
Re: Some reasons to work on productivity and velocity
#154I 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 - bei…
I think you're kind of mythologizing both FAANGs and Leetcode here. Leetcode won't get you further than doing amazing work and making your co-workers and colleagues happy. The OP is about how to get serious upgrades in the work you do. Leetcode is a thing that gets you in the door.
Likewise, FAANGs are not in every case "beautiful environments with amazing people dedicated to the craft of engineering." The most toxic person I ever met in my life spent years at Google, and he was not an impressive engineer by any stretch of the imagination. Amazon, Microsoft, and to a lesser extent Netflix are all notorious for having Squid Game cultures where everybody knows somebody will get fired soon and they're working hard to make sure it's not them.
Also, this is just false:
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.
I'm not saying it isn't true at any company. But as a statement about the overall industry, it's false. Great architectural decisions can add substantial amounts to a company's bottom line.
Likewise, this feels very naive to me personally:
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?
Principal engineer can be an astonishingly lucrative role.
Re: Some reasons to work on productivity and velocity
#155Earlier 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.
None of that experience translates to programming work imo
It does teach you about effort and pragmatic productivity, which is a general skill.
I've spent years trying to design code that would give me some benefits but in reality they were taking too much time for low use-case value. When you have time pressure, you write code very differently. You aim at the smallest patch that can solidly implement a feature. It minimizes code changes, patch size, bug introduction, time spent, client happiness. Also mentally beneficial to see tiny regular results.
Re: Some reasons to work on productivity and velocity
#156Earlier 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.
I offer nothing definitive, but one of the greatest benefits of StackOverflow has been to quantifiably classify most of the common problems in computer science, programming, analytics (and to a lesser extent the other StackExchange communities ...)
If you go there, search for a tag, sort by popularity, etc. - most of those techniques and approaches and patterns are, if not timeless, then mostly timeless and relevant.
Re: Some reasons to work on productivity and velocity
#157I 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 - bei…
> What is the track for promotion at most companies
A point he hammers home in the article is that he likes to be more productive so that he can go home earlier and do what he loves.
> Pure programmers are just low value cogs
The idea of improving productivity here is not only applicable to programming. One example he mentions is improving meetings. If you're a business person, you could improve at spreadsheet jockeying.
Re: Some reasons to work on productivity and velocity
#158Earlier quoted context omitted.
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 ear…
> "How fast can you implement a chat widget" doesn't allow for the exploration of alternative ways to engage with customers
If you make a list of alternatives, and you don't know which one is the best, having higher overall velocity allows you to try more options.
Re: Some reasons to work on productivity and velocity
#159The problem is the anti work mentality and other demotivating factors are a product societal issues. What existential question is being answered by improving productivity and velocity?
Re: Some reasons to work on productivity and velocity
#160Any tips on how to get faster? I find I'm always trying to learn the new code base or tech it's built on. I hate the hours wasted trying to find out how to do something I already know how to do in another stack. Then there is the time wasted trying to learn git after mercurial and then Docker. As for typing after loads of intentional practice I seem to have plateaued at 60-70wpm. No idea how to get beyond that.
> Any tips on how to get faster?
take the time to write quality code, design quality systems, debug things the right way, don't rush, take your time
before you know it, writing good code (and systems) becomes second nature and you will get faster as a result
in other words, fast people/teams know how to be fast because high quality is second nature and they don't waste their time fixing bugs and retesting again and again