Avoid over-abstraction (still working on this one myself).
Ask HN: What habits made you a better programmer?
61–70 of 103 posts
Re: Ask HN: What habits made you a better programmer?
#62Understand the domain really well. You have to live and breathe it. Not just the specific problem you are trying to solve but the bigger picture. It will give you the freedom to make macro level decisions regarding your code that can have a high impact.
Re: Ask HN: What habits made you a better programmer?
#63I work on what is most exciting to me and then switch when the excitement wears off, switching back again when the excitement comes back.
If nothing is exciting, if there's resistance (usually from lack of sleep, lack of exercise) then I focus on restoring my routine, and working on something easier like copywriting, email, invoice admin etc. until the excitement for something else wells up again. But I keep working. Often you need to just press on before the excitement comes back.
In the long term, I pick technologies I'm excited in, even if they bring short term costs. Connecting the dots, this process has lead to near-perfect strategy in hindsight.
This is counter-intuitive, but embracing NIH has actually made me a better programmer. It's the spirit of vertical integration. It's taught me how to do things and developed my understanding. Rather than using say an SMTP client, if I don't know how it works I dive in and write one myself. It costs the project in the short term, but in the long term the project at least has one more programmer who understands the nuances of another protocol.
Imagine a Google that outsourced their filesystem, data center, server racks, JS engine, browser, caching, proxying, map/reduce, machine learning, DNS, etc. Would they be as good as the Google of today? That's what separates IT from hackers. IT configure and use existing software. Hackers write their own. IT know how to "cobble together" things. Hackers understand things. Without the intimate understanding that comes from NIH, there is no room for the hack.
Being a better programmer is a long term motivation, and it's often the methods that pay off in the long term that contribute most towards this goal.
Re: Ask HN: What habits made you a better programmer?
#64Heavy 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 context-switching mode, instead of settling into one context and having it work on the problem behind-the-scenes.
Re: Ask HN: What habits made you a better programmer?
#65My list of n things:
http://quandyfactory.com/blog/41/top_10_programming_lessons_...
Re: Ask HN: What habits made you a better programmer?
#66Participating in programming competitions like IOI, ACM, Topcoder, GCJ, etc
How does that help? To me they seem like interesting puzzles, but with little relevance to problems in practical projects.
Re: Ask HN: What habits made you a better programmer?
#67[deleted]
Re: Ask HN: What habits made you a better programmer?
#68Caffeine. I'm surprised nobody has admitted this yet.
Too much caffeine is a real problem, though. Programming benefits from a calm and lucid mindset, not being manic and jittery.
Re: Ask HN: What habits made you a better programmer?
#69Thinking about problems away from the computer always seems to bring about the answer. It seems like I do my best thinking in the shower, only problem is the usual 10 min shower sometimes turn into 30-40 mins.
Re: Ask HN: What habits made you a better programmer?
#70Noticing 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…
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…
Try this.
Design your program from high-level and iterate through phases into low-level. So for instance, I want you to make a program that, lets say, is a customer database.
High level 0: I need a customer database
Level 1a: I have these storage requirements.
Level 1b: I need these inputs
Level 1c: I need data to exit the system in these ways.
Level 2: Diagram of work-flow processes (how it interacts with real people).
Level 3: Diagrams of how the database will look, identify what types of objects you will need to work with (of course, this specific action gears you into OOP design and not functional).
Level 4: Problems. Spend some time bad-mouthing everything and how it works, go back to level 2 and when you're tired of crying about the thing go onto the next level.
Level 5: Document how it works. This is your Manual.
Low Level 6: Write the code, and when you need guidance, RTFM.
Level 7: Throw the thing into the trash and start over, they wanted an inventory management system, another tribute to the synergistic perspicacity of business people and software engineering's verbal constipation.