Live data from Hacker News

A Programmer’s Greatest Enemy

jeffwofford.com

31–40 of 41 posts

Re: A Programmer’s Greatest Enemy

#31

Many times when I'm stuck, I seem to draw the conclusion that this is because the documentation is lacking. It might be me scapegoating, but many times I find that it is because there is a lack of documentation that I spend hours on hours trying to figure something out. Debugging on Windows, is a prime example. If you take someone from the normal Visual Studio give give them a PDB file, the compiled executable, limit…

Being stuck due to shitty docs is the worst. Particularly when docs are wrong, leave our crucial info, or the examples don't work (!).

Developers, please take pride in great documentation, and if you get stuck due to someone else's shitty docs, tell them at least, at best: fix the docs yourself. You can often write great (passionate) docs if you just had hands-on experience with the pain-points.

Also, make sure your examples work (examples+tests are often the best docs)

Re: A Programmer’s Greatest Enemy

#32
post #8

A programmer’s greatest enemy is getting stuck. Agreed. I often know where I want to go but can't seem to get there with code. This sucks and good programmers must find a way to get through this. A crucial skill in programming...is the ability to recognize when they’re stuck, Yes, and this is the only time I ever measure lines of code. Here is my metric: If I've been sitting at my computer (developing, not testing or…

I once was stuck for seven months. I never quite understood why my employer was OK with that. The solution however was just as you described. I needed to get away from the computer. In that case, I had to get some science/math straight. Once that was sorted, I steamrolled that roadblock in one evening. True story.

Re: A Programmer’s Greatest Enemy

#33

I'm really stuck. I hate my job and dread every day of it. I'm too scared to move on somehow because of some ill form of loyalty towards its owner and a limited job market here. I've dropped out of college (a really good one, you should know it) because I couldn't afford it any more and I'm now working as a .NET web developer (4 years) with people clearly less knowledgeable about programming and the internet in gener…

Sounds remarkably similar to my life in my early 20s.

Get out. Now. I spent about 5 years in a job that initially taught me a lot about a lot of different technologies, but I peaked very quickly. I felt like I couldn't leave, however, since I was easily the most technical and was responsible for lots of disparate systems. So, I would go to work and spend 95% of my day chatting on IRC and 5% of my day writing a solid chunk of code that made it look like I was busy.

The biggest regret I have is that I spent at least 2 years too many at that job before I grew the balls to change my life. Don't waste another day of your life rotting away in an environment that's doing nothing for you.

Re: A Programmer’s Greatest Enemy

#35

I'm really stuck. I hate my job and dread every day of it. I'm too scared to move on somehow because of some ill form of loyalty towards its owner and a limited job market here. I've dropped out of college (a really good one, you should know it) because I couldn't afford it any more and I'm now working as a .NET web developer (4 years) with people clearly less knowledgeable about programming and the internet in gener…

Currently in an almost identical situation. Finally made the decision to start an independent software business within the last month. Not sure how. Don't know what to make. Don't know how I'm going to market anything. But simply having the plan makes a huge difference. I feel so much better.

"with 30 minutes of coding I'm still more productive than any of ny work mates"

Use the rest of your time on research and planning for your own business. Don't actually do work on their computers, but research is fine. Feel absolutely no loyalty to the company. I guarantee they have no loyalty to you.

Re: A Programmer’s Greatest Enemy

#36
post #30

The five minute shout. If you are stuck for five minutes, ask the room. This is not an admission of failure. This is not an admission of incompetence. It's an admission that you're stuck. It's an admission that you are human. It's recognition that the project is more important than your ego. It's a chance to communicate with your team. It's a chance to laugh at your oversight. It's a chance to improve. Just ask. No h…

Depending on the work environment this might be good advice. On the flip side, however, I think many people have or remember having coworkers who ask questions any time they get stuck without hardly trying to solve the problem for themselves.

Spinning your wheels for too long doesn't help anyone, but a lot can be said for people who are independent and don't needlessly distract those around them.

Re: A Programmer’s Greatest Enemy

#37
post #30

The five minute shout. If you are stuck for five minutes, ask the room. This is not an admission of failure. This is not an admission of incompetence. It's an admission that you're stuck. It's an admission that you are human. It's recognition that the project is more important than your ego. It's a chance to communicate with your team. It's a chance to laugh at your oversight. It's a chance to improve. Just ask. No h…

Depending on the work environment this might be good advice. On the flip side, however, I think many people have or remember having coworkers who ask questions any time they get stuck without hardly trying to solve the problem for themselves. Spinning your wheels for too long doesn't help anyone, but a lot can be said for people who are independent and don't needlessly distract those around them.

This is an argument Spolsky once made in favor of offices I've always liked, from http://www.joelonsoftware.com/articles/fog0000000068.html.

"Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).

"Now let's move them into separate offices with walls and doors. Now when Mutt can't remember the name of that function, he could look it up, which still takes 30 seconds, or he could ask Jeff, which now takes 45 seconds and involves standing up (not an easy task given the average physical fitness of programmers!). So he looks it up. So now Mutt loses 30 seconds of productivity, but we save 15 minutes for Jeff."

Granted, interrupting a peer makes more sense if you actually can't make progress without another opinion on design, rather than just being lazy and using them as a living reference work.

Re: A Programmer’s Greatest Enemy

#38
post #18
post #8

A programmer’s greatest enemy is getting stuck. Agreed. I often know where I want to go but can't seem to get there with code. This sucks and good programmers must find a way to get through this. A crucial skill in programming...is the ability to recognize when they’re stuck, Yes, and this is the only time I ever measure lines of code. Here is my metric: If I've been sitting at my computer (developing, not testing or…

My trick for getting unstuck is to start maintenance on the part where I'm stuck. Any kind of cleanup, comment clarification and so on will do. Once I'm doing that I'm doing something and moving from doing something to doing what I want to do happens more or less automatic at some point. I got this trick from working in a metal shop. We'd get stuck trying to solve a problem all the time, and whenever that happened we…

That's a very nice way of looking at it.

I've found doing a bit of refactoring on messy code has always helped if stuck and the effect is just as you describe.

Re: A Programmer’s Greatest Enemy

#39

Earlier quoted context omitted.

Depending on the work environment this might be good advice. On the flip side, however, I think many people have or remember having coworkers who ask questions any time they get stuck without hardly trying to solve the problem for themselves. Spinning your wheels for too long doesn't help anyone, but a lot can be said for people who are independent and don't needlessly distract those around them.

This is an argument Spolsky once made in favor of offices I've always liked, from http://www.joelonsoftware.com/articles/fog0000000068.html . "Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity…

Also if your problem is that you don't understand some of the custom code, you often have no choice but to ask Jeff.

Re: A Programmer’s Greatest Enemy

#40
The real difficulty is in recognizing that you are stuck. You might be working on 10 different things. You may be making or ogress on 9/10 things. However the one thing that gets stuck may be holding you back on milestones. I've noticed in the past that I would put more effort to get the other 9 things going faster than put an effort to recognize that I'm stuck on a task and that's really important to achieve the milestone. I would be avoiding the task without even being aware of it. A personal project plan helps me notice the lack of progess on a task. I've been reading "Getting things done" by David Allen. Listing out things you need to get done and inventorying them periodically helps me to a certain extent.
Post reply on HN