Live data from Hacker News

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

news.ycombinator.com

151–160 of 538 posts

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

#151

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. This is THE big difference between S/W dev and IT. For 20 years I worked in the former, and for the past 10 in the latter. No question about it: IT is hell. Theirs is a never-ending mission to reduce the cost of moving data and being "compliant" with often-meaningless ever-excessive corporate standards (and forever meaningless MBA/CIO fad…

I've noticed this even walking around at work in different areas other than where I sit.

"Hey aren't you in IT can you help me with my computer issue"

One of the things I dislike the most is being referred to as "The IT Department".

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

#152
Shell scripting (which will lead into Unix internals). A lot of programming is automation and yak shaving, and shell is often the quickest tool to get past that. It lets you get to the meat of the problem you're actually solving.

Using the same tool for build, test automation, deployment, sys admin, refactoring, etc. is valuable. Otherwise you are stuck with frothy and immature domain-specific tools that clutter your brain.

Shell is sort of universal in that C/C++, Go, Python/Ruby/JavaScript, etc. programmers all use it.

It's sort of like the idea of mastering a single editor. You wouldn't want to switch editors every year. Likewise I think knowing shell and Unix really well pays off over the long haul.

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

#153
> What advice do you have for programmers just hitting their stride?

Stop calling errors, bugs. They're not cute things that just happen because all software has bugs. Software has errors. Trust your instinct to leverage tools to manage complexity and reduce the likelihood of introducing errors. Lean on sound typing, formal specifications, invariants and property-based testing. Learn to love restrictions.

Remember: tests prove the presence of errors, not their absence. It's much more powerful to state, formally, what your software will not do.

Also be creative and play. Take an idea to its extremes and let the haters hate.

Programming is beautiful!

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

#154

I spent a long time never bothering to master semi-advanced text editor or ide features. Like really simple stuff like moving forward/back by a word at a time, deleting a word at a time, hopping to next/prev brace/paren, renaming globally, doing everything without needing the mouse, multi-select etc. You can go even deeper and get into deep VIM style skills but there are many very easy things to learn that let you do…

Okay, so as someone who is less than 4 years into programming what are the key common shortcuts(not they're actual hotkeys just which ones are used the most) to learn for semi-advanced text editors and IDE's? EDIT: thanks for the advice guys, I use Jet Brains range of IDE's for school cause free licensing and I'm using VS for my summer internship. I'll look into emacs though, thanks for the suggestion!

Learn the multi-line edit thing in Sublime Text (or equivalent in your editor or IDE). Once mastered, make sure you do this brazenly in front of as many people as possible - it will blow their minds and probably get you an instant promotion.

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

#155

Use strongly typed languages for large projects

Adding my corollary, if you must use dynamically typed languages - ensure at any cost that you split it up into multiple small independent codebases.

And use type hints whenever possible.

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

#156
I wish I knew the importance of working on an idea that is mine. You'll not be influenced by external pressure or constrains. You can build it how it should be built according to you. Along with following the right people and working with smart people, this habit has helped me improve my skills across different domains.

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

#157
The company (any company and or manager) will try to get away with paying you as little money as possible. Even if it's below industry/region average, even if they know you're worth a hell of a lot more. They will offer the lowest pay bumps they think they can get away with.

You have to ask for more to get what you're worth. And it doesn't hurt to ask, worst case is they will say it's not in the budget (even then it's usually not a firm no).

The trick is during your review you have to say you want more. You have to present a case that you're worth more. And it's not even a hard or complicated case to make.

If you know what the industry standard is in your area and you're underpaid say "I think I deserve a pay bump of . The average rate for programmers here is so I should be at least making and you just told me I'm doing a great job, so I think I deserve a little more than average."

In all seriousness I'm basing this on past experiences (both myself and colleagues). You probably deserve more than you're being paid. The company will easily pay more than they offer by a little and most likely by a lot (if you're a good negotiator and make a good case).

The key is: ask for more, justify by reminding them you do a good job.

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

#158

You're going to read your code 100x more than you're going to write it. Optimize the code you write for reading. Your code will be in production either much longer or much shorter than you think it will. The 5 lines of code you spend three days perfecting will be replaced in a week, and that one-line 3am hack will be out there for ten years. A good walk around the block will help you solve a problem faster than stari…

>You will derive more long-term benefit from finding an answer yourself than finding that answer on Stack Overflow, at the cost of time. When time matters, at least try and understand why the Stack Overflow answer is right.

Absolutely agree! You have no idea how much I have learn from reading the official documentation of whatever tool I am using vs a basic stackoverflow answer with little explanation.

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

#159

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. This is THE big difference between S/W dev and IT. For 20 years I worked in the former, and for the past 10 in the latter. No question about it: IT is hell. Theirs is a never-ending mission to reduce the cost of moving data and being "compliant" with often-meaningless ever-excessive corporate standards (and forever meaningless MBA/CIO fad…

Having regrettably started from the IT side, it's seemingly impossible to make the jump to a software company proper. Nothing I do day-to-day is flexing any mental muscles an interviewer would find sexy. We're like a permanent underclass of undesirables. Without spending time outside work to focus on sharpening basic undergraduate CS knowledge, I know I'm getting objectively rusty at the types of problems I actually do have some remaining passion for.

I fear I'll be hammering out poorly-spec'd features to the beat of another department's Gantt-chart for the rest of my life.

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

#160
post #152

Shell scripting (which will lead into Unix internals). A lot of programming is automation and yak shaving, and shell is often the quickest tool to get past that. It lets you get to the meat of the problem you're actually solving. Using the same tool for build, test automation, deployment, sys admin, refactoring, etc. is valuable. Otherwise you are stuck with frothy and immature domain-specific tools that clutter your…

Agreed, I saw this posted the other day https://github.com/koalaman/shellcheck and it's been interesting.

I like some of the features in the other shells but bash is ubiquitous.

Post reply on HN