Ask HN: How do you work faster?
12 comments
Everyone has a different weakness when it comes to coding. You'll need to review your own work and figure out what took longer than expected before you can figure out how to improve on it.
Some people spend too much time overthinking the design, others jump in too fast and spend their time reworking prior design flaws. Some take forever doing the UI, others get stuck in the DB. If you can figure out what caused the biggest delay with your last project, you'll see the largest improvement if you fix it. I'm sure questions on a specific problem will get more help from others as well.
Some people spend too much time overthinking the design, others jump in too fast and spend their time reworking prior design flaws. Some take forever doing the UI, others get stuck in the DB. If you can figure out what caused the biggest delay with your last project, you'll see the largest improvement if you fix it. I'm sure questions on a specific problem will get more help from others as well.
Some thoughts:
1. Better to say "it will take me six weeks" and finish in five rather than saying it will take three weeks and finish in five. Even if it means you will lose a few bids.
2. Reuse your code and other people's code if available. I know this sounds obvious but not a lot of people do this. I don't code but I write reports and proposals and a lot of my content can be recycled with small tweaks between projects. I have seen coworkers rewrite entire pages that could have just been cut & pasted -- even from my report.
1. Better to say "it will take me six weeks" and finish in five rather than saying it will take three weeks and finish in five. Even if it means you will lose a few bids.
2. Reuse your code and other people's code if available. I know this sounds obvious but not a lot of people do this. I don't code but I write reports and proposals and a lot of my content can be recycled with small tweaks between projects. I have seen coworkers rewrite entire pages that could have just been cut & pasted -- even from my report.
I do UI design so I sam ure this won't apply but on the lotto-like chance that it might; I set up my work like an assembly line.
When doing HTML or MXML I concentrate on having all the art completed first including the wire frame or comp. Then I build the structure of the page, then work on presentation in CSS. I do not do HTML or CSS concurrently.
I think the key is to have a plan, make a procedure, then follow it. Don't bounce around.
When doing HTML or MXML I concentrate on having all the art completed first including the wire frame or comp. Then I build the structure of the page, then work on presentation in CSS. I do not do HTML or CSS concurrently.
I think the key is to have a plan, make a procedure, then follow it. Don't bounce around.
If I feel like I'm being inefficient because I'm not meeting my estimates, it's not because of efficiency, it's because I'm really bad at estimating the time a project should take. Just like any other developer out there.
There are a lot of articles out there for doing proper time estimation, and they are about as good or bad as all the articles for increasing productivity. That is, there isn't really a good answer for that except for seeing the same thing over and over again and knowing from that experience how long the individual parts should take. Anything I haven't seen before is just going to be a WAG (wild ass guess.)
Otherwise, I just have to be honest with myself on how I'm spending my time. Am I getting distracted a lot while working? Am I working solid days? If I need to be working six hour days but I'm routinely getting only 2 hour days of work and 4 hour days of watching cat vids, then I have a different problem.
I make sure that I'm getting real work done during my most productive hours. My most productive time is right after I get up, ridiculously early in the morning. If I'm reading hacker news during this time I can literally feel my life force draining from me. If I don't make the most of this time, then I'm losing out for the day.
Every developer has an optimum amount of productive hours per day. For me, it's four hours and I begin going downhill after that. Sure, I can spend 12 hours working, but the first four are productive and by the last two I'm a stumbling, bumbling mess, lucky that I can type out my own name. Like sleep, this is different for everyone.
Hours worked for me is like the inverse of sleep. If I use up my pool and go into reserves, then I'm that much less productive the next day. I always have to pay back my debt. So, if I'm wrong on my estimates, then working extra hours doesn't help. I just have to be honest with everyone concerned and let them know that the timeline is in trouble and needs to be extended. That's fine, communication and honesty will almost always make up for missed deadlines. Lack of honesty and communication is poison.
As a remote worker, I have the luxury of picking my hours. So, I have been slowly doing away with the idea of a weekend. If I feel super productive on a Sunday, then I need to be working. Then, if I feel unmotivated on Tuesday, I can take that day off knowing that I'm still on target for my hours worked and I didn't have to force myself and in doing so, being less productive.
A bit issue for me, especially when working on my own, is getting bogged down in an issue. Sometimes it's something that I'm having a hard time figuring out, other times it's me geeking out and trying to over-engineer something. I have trained myself to recognize the symptoms and immediately hit the alarm to have another developer come in and suggest an alternative route.
I can blame myself for letting in distractions for news and cat vids, but I have limited control over communication distractions with my team. What I try to do is get an expectation going that I have certain times during which I'm open for communication and which times I'm trying to be a productive developer. It's death for me to be spending a couple of hours in meetings during my most productive hours, much better to make myself available during times when I have already used up my productive time. That way mind numbing meetings help me get ready for naptime. ;)
I'm sure I could come up with a lot more, but this is the "off the top of my head" stream.
There are a lot of articles out there for doing proper time estimation, and they are about as good or bad as all the articles for increasing productivity. That is, there isn't really a good answer for that except for seeing the same thing over and over again and knowing from that experience how long the individual parts should take. Anything I haven't seen before is just going to be a WAG (wild ass guess.)
Otherwise, I just have to be honest with myself on how I'm spending my time. Am I getting distracted a lot while working? Am I working solid days? If I need to be working six hour days but I'm routinely getting only 2 hour days of work and 4 hour days of watching cat vids, then I have a different problem.
I make sure that I'm getting real work done during my most productive hours. My most productive time is right after I get up, ridiculously early in the morning. If I'm reading hacker news during this time I can literally feel my life force draining from me. If I don't make the most of this time, then I'm losing out for the day.
Every developer has an optimum amount of productive hours per day. For me, it's four hours and I begin going downhill after that. Sure, I can spend 12 hours working, but the first four are productive and by the last two I'm a stumbling, bumbling mess, lucky that I can type out my own name. Like sleep, this is different for everyone.
Hours worked for me is like the inverse of sleep. If I use up my pool and go into reserves, then I'm that much less productive the next day. I always have to pay back my debt. So, if I'm wrong on my estimates, then working extra hours doesn't help. I just have to be honest with everyone concerned and let them know that the timeline is in trouble and needs to be extended. That's fine, communication and honesty will almost always make up for missed deadlines. Lack of honesty and communication is poison.
As a remote worker, I have the luxury of picking my hours. So, I have been slowly doing away with the idea of a weekend. If I feel super productive on a Sunday, then I need to be working. Then, if I feel unmotivated on Tuesday, I can take that day off knowing that I'm still on target for my hours worked and I didn't have to force myself and in doing so, being less productive.
A bit issue for me, especially when working on my own, is getting bogged down in an issue. Sometimes it's something that I'm having a hard time figuring out, other times it's me geeking out and trying to over-engineer something. I have trained myself to recognize the symptoms and immediately hit the alarm to have another developer come in and suggest an alternative route.
I can blame myself for letting in distractions for news and cat vids, but I have limited control over communication distractions with my team. What I try to do is get an expectation going that I have certain times during which I'm open for communication and which times I'm trying to be a productive developer. It's death for me to be spending a couple of hours in meetings during my most productive hours, much better to make myself available during times when I have already used up my productive time. That way mind numbing meetings help me get ready for naptime. ;)
I'm sure I could come up with a lot more, but this is the "off the top of my head" stream.
As a reluctant project manager I have an insight: Maybe the real problem isn't that you're slow, maybe the real problem is that you're bad at estimating?
By the way your time may not scale: Humans can't really do multi-tasking, so the more tasks you ass the slower you do them all. So if you worked on just one project it would go fast.
Also you shouldn't think of code as writing the physical code: Most coders I know are spending their time thinking, coming up with structures and problem solving.
By the way your time may not scale: Humans can't really do multi-tasking, so the more tasks you ass the slower you do them all. So if you worked on just one project it would go fast.
Also you shouldn't think of code as writing the physical code: Most coders I know are spending their time thinking, coming up with structures and problem solving.
Agreed. We often forget that building a program is creating something out of nothing. Stuff takes time.
Not only that, but even if you are building something with off the shelf parts even that takes more time than you can imagine!
I think about this from time to time. How did I get there? How do I get further?
I started off really bad. I've progressed to "good", and hoping to get to "great" someday. I've picked up this wisdom:
1. Learn an IDE and an editor. The IDE is useful for refactoring, for project management, for code completion, and other niceties. Your editor is there to lean on when you have to do some down and dirty editing. For example, today I took a GORM class, copied the contents into vim, and within a few macros and regular expressions I had transformed it into the bones I needed for an HTML table in five minutes, as opposed to a half hour of copying, pasting, adusting, and making sure I didn't make some stupid error. Now, to be fair, for many years I was more comfortable staying in just Vim and can see why someone could just stay there, I think both are necessary. (Now, editors like Sublime in languages like Ruby may be close enough to an IDE that it doesn't matter, but I'll swear up and down that having a tool that contains the kitchen sink makes the 80% much more comfortable to me.
But by learning it, I mean really digging down and memorizing the keystrokes and being able to use without thinking. If it takes flash cards and repetition, so be it.
2. Great programmers don't have to worry about learning libraries -- they just figure them out. I am not a great programmer. I work to understand an API so that I don't have to think about it when I'm using it.
3. Most of our work is fairly repetitive in terms of the patterns we use, so figure out the patterns that work ahead of time and look for ways that you can avoid making decisions. Every time you have to think about something simple because there are two equally-okay ways to do that, you're slowing down.
4. In a similar vein, look for ways to write programs to simplify what you do, especially in terms of generating code. In any given project, many of our screens can be the same, especially in enterprise software. Instead of copy-and-modify, write a script that is repeatable. Even with the Don't Repeat Yourself maxim, there are far too many ways in which we may not be repeating the same code, but we're certainly repeating 90% of the same process of getting to a similar end result. If you see an elegant way to abstract that out, all the better, but code generation can be a useful tool.
5. Pair program with better programmers. See what kinds of patterns they use. Steal as you can. I had my greatest growth when I was on a project with a programmer I really respected and we paired. I got insight in to how he approached problems that I was able to take with me.
I started off really bad. I've progressed to "good", and hoping to get to "great" someday. I've picked up this wisdom:
1. Learn an IDE and an editor. The IDE is useful for refactoring, for project management, for code completion, and other niceties. Your editor is there to lean on when you have to do some down and dirty editing. For example, today I took a GORM class, copied the contents into vim, and within a few macros and regular expressions I had transformed it into the bones I needed for an HTML table in five minutes, as opposed to a half hour of copying, pasting, adusting, and making sure I didn't make some stupid error. Now, to be fair, for many years I was more comfortable staying in just Vim and can see why someone could just stay there, I think both are necessary. (Now, editors like Sublime in languages like Ruby may be close enough to an IDE that it doesn't matter, but I'll swear up and down that having a tool that contains the kitchen sink makes the 80% much more comfortable to me.
But by learning it, I mean really digging down and memorizing the keystrokes and being able to use without thinking. If it takes flash cards and repetition, so be it.
2. Great programmers don't have to worry about learning libraries -- they just figure them out. I am not a great programmer. I work to understand an API so that I don't have to think about it when I'm using it.
3. Most of our work is fairly repetitive in terms of the patterns we use, so figure out the patterns that work ahead of time and look for ways that you can avoid making decisions. Every time you have to think about something simple because there are two equally-okay ways to do that, you're slowing down.
4. In a similar vein, look for ways to write programs to simplify what you do, especially in terms of generating code. In any given project, many of our screens can be the same, especially in enterprise software. Instead of copy-and-modify, write a script that is repeatable. Even with the Don't Repeat Yourself maxim, there are far too many ways in which we may not be repeating the same code, but we're certainly repeating 90% of the same process of getting to a similar end result. If you see an elegant way to abstract that out, all the better, but code generation can be a useful tool.
5. Pair program with better programmers. See what kinds of patterns they use. Steal as you can. I had my greatest growth when I was on a project with a programmer I really respected and we paired. I got insight in to how he approached problems that I was able to take with me.
>2. Great programmers don't have to worry about learning libraries -- they just figure them out.
I would love to be able to do this. The amount of time I'll ponder on a library thinking "what are the internal mechanics of this?" can be quite frustrating. For OpenGL, for example, I have such a hard time processing a mental image of the system that I can't really figure out how to use it well.
Every library should have their first page be an explanation of how everything goes together, in layman's terms. The fact that the X server books had a huge introduction explaining everything really helped me understand the otherwise ungrokable code.
I would love to be able to do this. The amount of time I'll ponder on a library thinking "what are the internal mechanics of this?" can be quite frustrating. For OpenGL, for example, I have such a hard time processing a mental image of the system that I can't really figure out how to use it well.
Every library should have their first page be an explanation of how everything goes together, in layman's terms. The fact that the X server books had a huge introduction explaining everything really helped me understand the otherwise ungrokable code.
That's what examples are for. Start from working code; make it your own.
Sure it helps to have a mental model. But how to achieve that? Expect it to take time, and digging right in and looking at those examples, and changing them to see what works.
Sure it helps to have a mental model. But how to achieve that? Expect it to take time, and digging right in and looking at those examples, and changing them to see what works.
[deleted]
Although my code is "good" (my employers tell me as much), I just wish it didn't take so long. It was the same with mathematics homework in school. I remember doing well in my Theory of Computation class but I always took so long on the homeworks and for one exam I had to request extra time to finish the last problem.
I feel like being able to efficiently craft code in a reasonable time would be a major breakthrough.