Live data from Hacker News

Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

news.ycombinator.com

301–310 of 538 posts

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#301
post #108

A reliable build pipeline is your most valuable asset. It could even be argued that what you build should be determined by whether your build pipeline can build it. Tinker with the pipeline at your peril. Be very careful what you do with it. Only when you are sure it works, submit new capabilities to it.

More generally, tooling matters. Your editor matters. Your compiler matters. Your tests matter. Your source code control system matters. Your bug tracking system matters. Pay attention to pain in these areas. When you keep finding that it's clumsy or tedious to do something, look for ways to make it better.

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#302
post #185

Work somewhere where software is the main product and not just a cost center. You can learn a lot quickly if you do cutting edge things with people who care about technology and not just cost. Solve real world​ problems. Doing elegant things is very difficult because the real world is much more convoluted than theory. Do a few things in depth. Don't jump at the latest thing every few months.

> Work somewhere where software is the main product and not just a cost center. I've done both and I can't say one is better than the other. I've worked on software products where marketing couldn't figure out how to sell it and kept changing the core functionality. Or where the CEO kept shoving his ludicrous ideas onto development. I've worked on rewarding IT projects where I worked very closely with the users and w…

> After 28 years, I ended up preferring working close to the actual users.

This is key.

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#303

My wife hates it when I say this. (She's QA, I'm dev.) One of my best skills is assuming. I have to make tons of assumptions, and if I stopped working whenever I didn't know the answer for sure, I'd never get anything done. Instead, I make my best guess. If I'm unsure enough, I'll also send off an email stating my assumption and asking for direction, but I'll still keep coding based on that assumption. I am almost al…

"but I'll still keep coding based on that assumption." That's terrible advice. If you're unsure of what you're supposed to be doing, you should close the computer and start exploring your options with pen and paper before doing more damage. If you keep going based on assumption, you drive halfway across the country in the wrong direction like in Dumb and Dumber. Sometimes it's better to do nothing at all than to infl…

Personally, I don't view "wrote a bunch of code based on an incorrect assumption" as "damage." At worst, you have to revert to what you started with and rewrite it. What were you going to be doing in that time anyway?

Basically, when I hit a roadblock that I can't get around by working on something else while I wait for clarification, my process is as follows:

1. List my options.

2. Pick the best one.

3. Send an email to my boss outlining the possible options, and note that I've picked what I think is the best possible option.

4. Continue coding and know that I might have to rewrite that feature if my assumption was incorrect.

If you're right, great - it wasn't a roadblock. If you're wrong, you modify or rewrite... which isn't too big of a deal, as you would have been picking your belly button lint while waiting for an answer anyway.

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#304

Everyone's code basically sucks, including yours. The boundary between a beginner and a coding rockstar really isn't very great unless you are getting into the realm of computer sciences, like machine learning. Learn from your seemingly smarter peers, but don't idolize them. Chances are they will leave the company long before you do, and you will figure out that their coding skills aren't all they are cracked up to b…

A corollary of your first point is that it is code that is bad, and not your coworkers. Code is complex and nobody really knows how to program. (Proof: If folks did know how to program, then we wouldn't fight over which programming language is the right one; it'd be obvious.) So don't ever blame your coworkers unless they're deliberately malicious; instead, have compassion for them and for yourself as well.

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#305
post #56

There is no future in software development as a job. Move to a management position quickly, network, make friends with decision makers, don't spend too much time on crafting your skills, your reward for perfection will be more insane work and crazy interviews where one part not 100% done kicks you out. Work on your appearance, kiss up, lift, dress properly, use anti-aging cosmetics, make cool looking hairstyle, wear…

> There is no future in software development as a job. Wrong. I've been at it for 30 years. It's not all roses, but it's still pretty good. The key is to be doing something where 30 years of experience is worth more than 5 years of experience. I'm in embedded systems, and the experience matters there (to enough people, even if not to everyone). Web programming? I'm less convinced that it matters there. > Move to a ma…

At some point your brain stops working, you won't be able to compete with fresh graduates, the capability:wage ratio will be very low in your case; you'd get a prompt boot, never to be able to be employed on the same level again. Experience in our field has negative value and unless you get another M.S./PhD every 10 years to demonstrate you are still on top, you are toast.

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#306

You don't have to design the whole thing before you implement. This applies more easily to smaller teams but there's a continuum between rapid dev and thinking everything out. In my game dev it took me a long time to let go of "but I need to create an elegant/clever solution that covers all my planned features rather than just what I'm implementing now". What that got me was a lot of unfinished projects with elegant…

This was one lesson I had to learn to progress faster both at home and at work. Start building now and don't be afraid to refactor later. The caveat to that is to refactor frequently as things progress. If a function is now misnamed because it's code changed too much, rename it. If your carefully thought out code structure just isn't going to work, change it now before it's a major pain to do so. Don't assume you will get back to it later, you won't.

I don't know how others work, but I had a tendency to try to code the whole thing in one go. Now I build the skeleton and start fleshing it out piece by piece, with an end goal in mind. It's very iterative. Do the next thing, whatever it is, large or small. Build and test. Refactor if needed. Rinse and repeat. I have to have it roughed out before-hand, but it will almost always change a bit as I get into the nuts and bolts of it unless it's trivial. Now I adapt as I go. The design reveals itself :)

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#308

What I have learned is: * Typed languages while more complex are worth it (circa 12 years ago I was a heavy scripting language fan) * Unit tests that heavily use Mocks are almost always a bad sign. Brittle tests suck. Don't increase coverage for the sake of it. * Get it done and move on. Try not to obsess on little details that add no value. * "It depends" * NIH (not invented here) is not always bad. In general it ac…

Definitely true about mocks in unit tests. I've seen some nightmare projects where >50% of the code is just setting up mocks for unit tests.

Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

#310

If you're self taught, get a degree as soon as you can, even if you take night classes over an extended period. No matter how good you are, a large portion of companies and recruiters will autotrash your resume without an education section. If you're not a founder, NEVER take equity in leu of salary. If they offer a competitive salary and equity, that's a significant plus, but equity as a portion of your compensation…

> If you're self taught, get a degree as soon as you can, even if you take night classes over an extended period. No matter how good you are, a large portion of companies and recruiters will autotrash your resume without an education section.

Not true. I'm self taught and I had very generous offers from the two of the three big names.

Screw spending a time to getting a degree just for the sake of it and build stuff.

I know it wasn't like that before, but times have changed and so have recruiters.

Post reply on HN