Live data from Hacker News

Some reasons to work on productivity and velocity

danluu.com

171–180 of 183 posts

Re: Some reasons to work on productivity and velocity

#171
post #170
post #97

Earlier quoted context omitted.

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…

What are the 'chunks' of competitive programming? Like knowing how to make a graph, use hash tables / arrays well, a typical dynamic programming solution and so on?

No, its mostly how to structure the full computation flow for different things. If there were an easy set of patterns then it would already be in some book, these things are skills you can't put in a book.

For example, when is it useful to create a function instead of writing the code inline? Many times the amount of code grows exponentially with problem size unless you properly create good functions, so you need to learn to get good at that. Code reuse also greatly improves how fast you can write the solution and reduces bugs, so it is good even when it isn't absolutely necessary.

Where should the data be, who should own what data, how is the data supposed to be found where you need it? And so on. Many problems requires you to create quite elaborate data structures and relationships, finding the right data in a reasonable amount of time is one of the hardest problems to solve even in competitive programming.

Caching and lazy computations as well, it is used everywhere in competitive programming. The fastest solution is where you don't do anything at all, so you get good at understanding how and when to cache results, when to throw out caches in order to handle new data etc.

Writing proper tests, since you get no credit if your code fails for any case you need to write tests that stresses all parts of the code you are unsure about. This teaches you to get really good about understanding the weaknesses in the code you write, debugging and creating solutions that are bug free.

Stuff like that is really important to get good at competitive programming, you need to be able to get good answer those questions in minutes for complex problems if you want to compete with the best in the world. Now you might notice that many basic data structures and algorithms are just solutions to the above problems, the point is to learn many generic cases of the above so you can compose your own data structures and algorithms as everyone of the harder problems requires you to do that.

And as you can realize these things are very useful for any sort of program, not just competitive programming. Managing data layouts and when it is useful to create functions is the majority of normal programming, if you can do those really quickly then there isn't much left that will take time.

Now, the bad rep competitive programming has is mostly that people just do the easy problems that can be summarized as "implement this basic algorithm". Real competitive programming isn't like that at all. Of course you need to be able to do the simple algorithms, but knowing how to implement the algorithms is just table stakes.

"Don't I practice these things when writing normal programs?"

Not in the same way. Competitive programming is about doing these in their pure form. In normal programming there are so many other things that it is hard to focus on the code, while in competitive programming all you have is code and then a really good test suite you can do to verify your solution once you think you are done. This way you practice a huge range of programming chunks really quickly, compared to trying to test them out and learn them in real world codebases.

Edit: Btw, last time I checked Leetcode didn't have many questions that stresses these important points, its mostly just useful to learn algorithms used in these interviews, it isn't good to learn programming. There are many good competitive programming sites to use instead. Leetcode is good if you want to pass interviews with minimal effort right now, but it isn't good if you want to get good. Also you just get good at chunks, you will still need to practice writing and structuring larger programs and solutions. But practicing that is way easier when you have mastered these chunks.

Re: Some reasons to work on productivity and velocity

#172

Earlier quoted context omitted.

The the first thing to do if you want to improve that is to ensure you track code reviews. Meaning, you can see what changes each person reviewed and not just submitted, and then you can use that data to talk about performance etc. If one person does all the reviews then he should get a ton of credit since that is hard important work. Typically lead programmers do more reviews and juniors writes more changes, so a pe…

There's a huge problem with this. The incentive you are describing isn't to do good code reviews. The incentive there is to do a lot of code reviews. Those two are not the same and while they are not mutually exclusive, just by tracking this metric and rating people on it, you are not giving an incentive for good code review. Only for fast review. But you really want both. You want fast and you want good and thorough…

The incentives for reviewing code should be exactly the same as the incentives for writing code.

So the most important part is that the reviewer should be just as visible in all processes and tools as the writer of the code. That way both gets recognition and both gets the blame when the code is bad or adds technical debt. And for performance reviews you don't just look at all the code they wrote, you also look at all the code they reviewed.

You are right that it is dumb to just count the number and say more is better, but the same goes for code submissions. They are very similar problems though so you can just use the same process for both of them.

Re: Some reasons to work on productivity and velocity

#173

Earlier quoted context omitted.

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 s…

I argue that those things are a different skillset and don't have overlap with the previous examples.

Re: Some reasons to work on productivity and velocity

#174

Earlier quoted context omitted.

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 s…

I argue that those things are a different skillset and don't have overlap with the previous examples.

Strange, to me its obvious. When you have to be tight you learn to be tight, you aim for faster, leaner operations.

Re: Some reasons to work on productivity and velocity

#175

Earlier quoted context omitted.

There's a huge problem with this. The incentive you are describing isn't to do good code reviews. The incentive there is to do a lot of code reviews. Those two are not the same and while they are not mutually exclusive, just by tracking this metric and rating people on it, you are not giving an incentive for good code review. Only for fast review. But you really want both. You want fast and you want good and thorough…

The incentives for reviewing code should be exactly the same as the incentives for writing code. So the most important part is that the reviewer should be just as visible in all processes and tools as the writer of the code. That way both gets recognition and both gets the blame when the code is bad or adds technical debt. And for performance reviews you don't just look at all the code they wrote, you also look at al…

And that last part unfortunately is what happens in a lot of companies. Basically taking something like your comment I replied to: "Look at metric X" and verbatim looking at that metric and only that metric (or maybe that and 2 or 3 others) and there's your performance review.

You mentioned another metric "code submissions", so say the number of reviews done is augmented by number or PRs merged. You've just created another incentive to just get a lot of code out fast.

After all, that's the point of the metrics, right? Have a few numbers that accurately describe the "value" of that employee. No qualitative analysis needed, that would take time and money we don't have. Been there, had to do that (or write huge amounts of text to say why I think that this employee is actually really good at what they do and the number of PRs they did was low because they got the short end and worked on the hardest problems in the worst parts of our code base and did an amazing job especially given they were new.

If that's not how it's actually done where you work, great!

Re: Some reasons to work on productivity and velocity

#176
post #170

Earlier quoted context omitted.

What are the 'chunks' of competitive programming? Like knowing how to make a graph, use hash tables / arrays well, a typical dynamic programming solution and so on?

No, its mostly how to structure the full computation flow for different things. If there were an easy set of patterns then it would already be in some book, these things are skills you can't put in a book. For example, when is it useful to create a function instead of writing the code inline? Many times the amount of code grows exponentially with problem size unless you properly create good functions, so you need to…

Out of curiosity. What would be the best way to learn these skills in your opinion? What are these "many good competitive programming sites" that you recommend?

Re: Some reasons to work on productivity and velocity

#177

Earlier quoted context omitted.

> Before thinking of improving specific skills, just being able to be focused and working without distraction all day every day would be an order-of-magnitude improvement for me. I solved this problem by going to a psychiatrist, getting diagnosed with ADHD (at age 35), and starting medication. Not an exaggeration—I struggled with compulsive video gaming for almost my entire life; now on medication that issue has just…

Thank you. I was fearing/expecting someone to mention ADHD. I have never been formally diagnosed but everything I read about it feels suspiciously similar to the way my brain is wired. I might have to look into it more seriously. I’m currently 33.

Nothing to fear, if you do have it your brain has always been this way so in a sense nothing has changed. That said a diagnosis can bring a lot of clarity, understanding, and help you form strategies to do better.

If you seek evaluation, seek it from someone with a lot of experience with Adult ADHD. If you get a diagnosis, make sure you work with a doctor who starts you at the lowest dose and slowly ups it as needed.

How to ADHD is a great YouTube channel, if you are curious.

Re: Some reasons to work on productivity and velocity

#178

Earlier quoted context omitted.

Thank you. I was fearing/expecting someone to mention ADHD. I have never been formally diagnosed but everything I read about it feels suspiciously similar to the way my brain is wired. I might have to look into it more seriously. I’m currently 33.

We didn't evolve to sit and focus for hours per day, some people can still do it but others need medicine. The main thing the medicine does is tell your brain "now is the time to focus, don't look for something else!". If being able to do that would feel life changing to you rather than just helpful then you should go get tested.

I agree with your general message and positivity but it is worth mentioning that Adderall, and stimulants, work differently in an ADHD brain vs. a neurotypical brain. The biggest effect I notice is not focus in a pill but instead a calming effect on the brain.

This has a profound effect on things not related to focus like background anxiety, mild depression, impulsivity, managing relationships etc.

Re: Some reasons to work on productivity and velocity

#179

Earlier quoted context omitted.

No, its mostly how to structure the full computation flow for different things. If there were an easy set of patterns then it would already be in some book, these things are skills you can't put in a book. For example, when is it useful to create a function instead of writing the code inline? Many times the amount of code grows exponentially with problem size unless you properly create good functions, so you need to…

Out of curiosity. What would be the best way to learn these skills in your opinion? What are these "many good competitive programming sites" that you recommend?

The site I used is codeforces.

https://codeforces.com/?f0a28=1

It has the widest selection and types of problems as far as I know but that was a while ago. It runs competitions all the time, the problem descriptions are well defined unlike leetcode which often misses a lot of requirements, it has way more kinds of problems than topcoder, you can test yourself against old competitions as if they ran real time to properly ensure you don't take too much time or accidentally cheat etc.

> What would be the best way to learn these skills in your opinion?

I think today it is hard to practice without competitive programming. Ideally someone would make a similar format pushing your limits like this but without so much focus on complex algorithms and maths, but since that doesn't exist competitive programming is what we are left with. The competition aspect is really important since it is how people push each others limits. It is easy to think "you can't get much better than this" when you just sit and code by yourself, but in programming competitions you see how fast and accurately others can solve problems, so you realize that you could get just as fast and accurate with a bit of practice.

And no, it is not memorization. Consider this easy problem which mediocre competitive programmer manages to solve but those below mediocre fails at (we can see that from how well people did on it in the competition):

https://codeforces.com/contest/1496/problem/B

There is no algorithm you have to know for that, it is just good old logic and some coding. It is really easy and I could solve in in a few minutes even my todays rusty self, but you can't memorize solutions to such problems, you just have to be fast both with the reasoning and the code. Note "mex" is not a standard term, it is just something they made up for that problem.

Re: Some reasons to work on productivity and velocity

#180

Earlier quoted context omitted.

Out of curiosity. What would be the best way to learn these skills in your opinion? What are these "many good competitive programming sites" that you recommend?

The site I used is codeforces. https://codeforces.com/?f0a28=1 It has the widest selection and types of problems as far as I know but that was a while ago. It runs competitions all the time, the problem descriptions are well defined unlike leetcode which often misses a lot of requirements, it has way more kinds of problems than topcoder, you can test yourself against old competitions as if they ran real time to prope…

Thank you for your very detailed and helpful replies.
Post reply on HN