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

Ask HN: What habits made you a better programmer?

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 103 posts

Re: Ask HN: What habits made you a better programmer?

#71

Post by 9ec4c12949a4f3 »

DanielBMarkham wrote: post #64

Heavy caffeine usage and liberal alcohol usage on occasion. Avoid both of those. When I have a a problem I do one of two things: 1) I work on trivial things like code cleanup and reorganizing things, or 2) I get my head completely out of the computer. Go for a walk. Sit outside and just look around for a few minutes. The anti-pattern here is popping off to look at your email, FB, or HN. It keeps the brain active in c…

>Heavy caffeine usage and liberal alcohol usage on occasion.

>Avoid both of those.

I'll keep it short and sweet. Family, religion, friendship ... these are the three demons you must slay if you wish to succeed in business.

Re: Ask HN: What habits made you a better programmer?

#73

Post by troels »

jakevoytko wrote: post #12

Noticing pain points. It takes time to develop a taste for good solutions. But when you modify or write code, and you say, "this is harder than it should be," this is a code smell and there is a better way to globally solve the problem. Thinking first, writing later. When practicing for the ACM programming competitions in college, I discovered that when writing code before understanding the solution, I eventually nee…

"Thinking first, writing later. When practicing for the ACM programming competitions in college, I discovered that when writing code before understanding the solution, I eventually needed to start over. I have never seen a counterexample."

The thing is. Some times writing code is how you best come to understand the solution. One of the things that have made me a better programmer, was exactly realising this. If there is something I don't understand, I now try to program it, rather than thinking too much over it first. Call it prototyping if you want. It's a fine line of course.

Re: Ask HN: What habits made you a better programmer?

#74

Post by mkr-hn »

yason wrote: post #45
dasil003 wrote: post #25

Earlier quoted context omitted.

I definitely won't disagree with anything you said in the general case, but for this: Thinking first, writing later .... I discovered that when writing code before understanding the solution, I eventually needed to start over. I think this may depend on how and when you think most effectively. Having the discipline to be productive in pure thought is impossibly difficult to quantify. At times I feel productive workin…

There's no clean path with regard to this. Either you plan too much ahead and you end up tweaking your design forever, eventually building high-level cruft code that still won't get anything done because you don't dig deep to the ground to find the real culprits of your solution. Alternatively, you plan nothing at all and end up rewriting your program several times because you just won't see the big picture as you're…

Since I'm still in the early stages of learning to program (past the "durr what are for loops" stage, but still not good at a language), I've found that it's nearly impossible to really plan anything out.

I can plan out what I'll put stuff in and the names of the classes and methods that'll work with data, but I'm clueless until I start trying to implement the idea.

I suspect that once I've done enough things, it'll be easier to plan. I know when I go back to any of my old C# projects, I keep slapping my forehead and am able to see other (often better) solutions.

So I think the better advice is: Try until you know what you're doing, then toss it out and plan around all the terrible mistakes you made.

Re: Ask HN: What habits made you a better programmer?

#76

Post by mkr-hn »

locopati wrote: post #28
ja27 wrote: post #24

Never just shrugging some problem off with "boy that's weird." I usually can't let something go until I understand what caused an issue. It eventually became unrealistic to chase down every oddity, but I've done enough of them to learn a lot about different pitfalls.

Funny because that's one of the things that I've learned - when to let something go as 'that's weird' and just solving the problem without spending days digging into root causes. Sometimes it's worth it, but usually it's taking time from getting other priorities accomplished.

When I run into a perplexing thing like that, I put a tag on it so I know to come back later once my mind has had time to work on a different problem.

Re: Ask HN: What habits made you a better programmer?

#77

Post by Mentat_Enki »

binomial wrote: post #51
anatoly wrote: post #43

Being aware of and managing my ignorance. I don't know if I can describe this very well, and I've only recently started explicitly noticing this about myself, but I seem to have a well-developed intuition of how much I am "in the dark" about a particular domain, problem, technology, library, behavior, etc. I seem to sense well (and can back up with explicit arguments if necessary, but it stars with a feeling) when th…

I have a lot of "darkness" around me concerning threading, but isn't it a net win even with the GIL if the threads are mostly waiting for IO to finish?

I think he means attempting to solve the 'symmetric multiprocessing' problem using threads, rather than using threads for sensible things like IO-forking/event-driven, asynchronous stuff.

Re: Ask HN: What habits made you a better programmer?

#78

Post by tmsh »

anatoly wrote: post #43

Being aware of and managing my ignorance. I don't know if I can describe this very well, and I've only recently started explicitly noticing this about myself, but I seem to have a well-developed intuition of how much I am "in the dark" about a particular domain, problem, technology, library, behavior, etc. I seem to sense well (and can back up with explicit arguments if necessary, but it stars with a feeling) when th…

Negative capability

http://en.wikipedia.org/wiki/Negative_capability

isn't quite the same thing, but it may be related. Flexibility with ignorance can lead to better understanding of one's ignorance and faster adaptiveness overall.

Per programming productivity, I think it about with stacks or queues. There's always something you can work on -- and variously they all eventually 'dovetail' together.

Re: Ask HN: What habits made you a better programmer?

#79

Post by euccastro »

j_baker wrote: post #34
dasil003 wrote: post #25

Earlier quoted context omitted.

I definitely won't disagree with anything you said in the general case, but for this: Thinking first, writing later .... I discovered that when writing code before understanding the solution, I eventually needed to start over. I think this may depend on how and when you think most effectively. Having the discipline to be productive in pure thought is impossibly difficult to quantify. At times I feel productive workin…

I think you're both right. Some people do like the grandparent suggests and map their strategies out in advance. I personally do better with Brooks's "build one to throw away" approach. I like this better because I can't work with a plan like others do. I need to have implemented something before I can understand it. Others work better with a different approach. To each their own.

They're not mutually exclusive approaches anyway. Alternating between them quickly can be a good way to nibble away at hard problems. And it's not a big deal if you throw away some work in either mode. Think on what takes you there faster, not necessarily with less (wasted) work.

Re: Ask HN: What habits made you a better programmer?

#80

Post by smutticus »

I believe that the quality of the code you write only shows itself over time. Every other metric we use to measure quality is subservient to one simple truth. How does your code age?

How easy is your code to modify later when you need to add a new feature? I think that's the only measure of good code that I trust. I get a little proud of myself when I need to modify something I've written previously to add a new feature and it's relatively easy. So I look back at how I wrote it then and try to learn from it. The opposite is also true. If I need to modify my code to add something and it is truly painful then I know I did something wrong way back when. The same is true for bugs found. If every bug found requires massive code changes than I did a pretty piss poor job initially. But if most bug fixes only require a couple of lines than I did well.

This makes identifying good and bad practices especially difficult because it requires that you stick around for things to fall apart. This is one of the reasons that commercial software sucks so much and why consultants leave giant messes in their wake. The short-term priorities of business conflict with the long-term reality of determining software quality.

As a developer it's your obligation to learn from your past mistakes and better yourself.

Post reply on HN