Live data from Hacker News

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

news.ycombinator.com

381–390 of 538 posts

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

#382
post #305

Earlier quoted context omitted.

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.

False so far, and I'm 55. I kick the rear end of fresh graduates. They can type a lot faster, turn out more lines of code per day. Great. I don't write the bugs that they write, so I don't have to take the time to find and fix them. I don't make the design mistakes that they make, so I don't have to fight the design flaws to get things done. They work harder; I get more done, and I get paid accordingly. And if you th…

Where I come from ppl your age get downsized and replaced by younger employees with less pay. The +50yo will never get a job but is still +15 years away from pension. At the end of tge day only the money matters. You can't pay rent on "job satisfaction". Neither can you eat it or retire on it.

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

#383
1) When adopting tools, methodologies, and practices, think about /why/. Don't use things because they're "good practice", look at what problem they solve, see if they solve your problem, adopt or adapt accordingly.

If you're going to use design patterns, great. But don't argue about the exact official gang of four definition of the facade pattern - a more productive conversation is about which specific bits of the pattern help you solve your problem and which are an impediment.

Tests great, but when you're just starting a brand new project where the behavior and spec is changing as you build and learn, should you suffer through brittle unit tests because "not testing is bad practice", or could you perhaps start only with integration tests, and wait a little bit until you start doing anything more granular?

Complex git branching / release / hotfix / etc schemes can be great in a larger organization, but when you're on your own, do you really need all of it or is it too much overhead? If you don't have a staging environment, should you have a staging branch?

Summary: a) Am I actually trying to solve a problem? What problem am I trying to solve? b) Is this thing going to solve my problem or a problem that I don't have? c) What can I change so it /does/ solve my problem?

2) In a large enough codebase, there is always bits that are shitty for a variety of reasons involving bad programmers, bad practices, no practices, bad requirements, terrible deadlines, old tech, whatever. You don't /want it/ to happen, but it will. Or perhaps you'll be dropped into that codebase, and so you'll have had no say to begin with. An unappreciated part of the practice of software architecture is about containing current and future shittiness, stopping it from spreading, managing the risk around that, not allowing that to impede current development, setting up a surrounding architecture, getting people on board socially to do the right thing, having a good plan to replace it and acting on that. "No new code until everything is clean and tested" sounds so valiant, but I'd like to see it happen in a 100 person organization with bills to pay. Alternatively, after you've contained things, then you can feel free to adopt such policies at a smaller scale within well-defined regions of the code.

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

#384

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…

> No matter how good you are, a large portion of companies and recruiters will autotrash your resume without an education section.

If the company looks that closely to academic degrees, it most probably doesn't know how to hire staff. I don't want to be the only competent person around.

> ([...] two years or more, a lifetime in this industry)

Where "this industry" is "startups plus websites". General IT doesn't move that fast, especially with regard to good tools and ideas. A carefully chosen toolbelt of things that are ten-fifteen-twenty years old is still stronger and more flexible than most of the new sexy applications programmers now use.

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

#385
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…

I absolutely disagree.

    There is no future in software development as a job
How can you make such a blanket statement? Software is a more lucrative position for more people now than ever in history. You want to be a manager?? Who will you be managing?? Programs that write other programs??

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

#387

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.

I agree with all of this and I think there is a third category of job where is software is neither the main business, nor IT. Once you have developed the necessary software skills in a "software house", in my experience, the best thing to so is to get stuck into a particular domain , where the company needs software developed (not IT), but is not the main business. These jobs and contracts attract the best $, but als…

[deleted]

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

#388
post #351

Earlier quoted context omitted.

I agree there is a balance to be met. For greenfield applications, chose whatever the customer ask for on their Request For Proposals, or suggest modern solutions if they leave it open to proposal reply. On existing solutions, deployed for several years on the field, actually measure what it brings in regarding business value. Either in terms of reducing project costs thus improving profit, or improving customer UI/U…

> What I am against is just adopting tech that doesn't improve anything How do you know what improves what if you don't use it in anger?

Pilot projects, technology analysis, market research, reports from external consulting companies, architecture assessments, university projects,....

There are many ways to research new tech without touching the current product development.

Sometimes it is better to be the turtle than the rabbit.

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

#389
Invariants is the key concept to writing good code.

Going for a walk and thinking things through yields better code faster than iterating over it hands-on.

Frameworks are overrated and often a source of ephemeral knowledge and code bloat. Think twice before committing to a framework or a 3rd party library.

Also, picking a good name for a variable may take up to a day.

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

#390
post #36

If I could go back in time and give myself advice it would be: 0) Nothing is too hard to do, no matter how much those doing it might seem like towering titans many levels above you, or how out of your reach it may seem. Nothing is too hard, there are only things that take time, and things that take more time. If you put in the work, those titans will be your peers before you realise it. Of course, you can't do everyt…

Regarding 2, how do you suggest I avoid "spinning my wheels and learning nothing"? Over the last 6 months I've becoming increasingly aware of this problem with me, but I don't know how to fix it.

Keep a technical journal: https://news.ycombinator.com/item?id=14315213
Post reply on HN