Go beyond the code. Learn UX, DevOps, QA, look at other engineering disciplines. Improve soft skills. Learn management and laws. Learn design and arts. You may not become good designer or manager, and you'll probably never be a lawyer, but everything can contribute to your success on many different stages of SDLC.
Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
401–410 of 538 posts
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#402You'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…
> A good walk around the block will help you solve a problem faster than staring at code.
This has really helped me out with some nasty bugs.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#403Earlier quoted context omitted.
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??
Programs will write other programs, there is extensive work on this problem in progress with some nice low-hanging fruit available in research already. The future will need genius-level swengs only, all mundane/boilerplate/lookup tasks will be done by semi-automated systems and most swengs won't be needed anymore. I am working in this field and can clearly see where it goes and we finally have means to accomplish it…
We go through this once a decade. The problem is a fundamental byproduct of the disconnect between humans, to whom mathematics and logic are foreign concepts that take consistent work to internalize and apply, and machines, for whom ambiguity, context, and perspective are foreign concepts that take consistent work to "internalize" and apply.
Call me a philistine, but I don't really believe we will ever get the natural->logical language mapping perfect enough to obliterate the need for developers on a massive scale. New languages beget new possibilities, which companies want to employ people to exploit, and so on.
Higher-level languages have "obsoleted" the task known as "programming" over and over again, to the point where there will often be 4-5 "automatic programming" layers between the code written by a person and the code that a physical machine executes. It's been 35+ years since your average developer would write machine code directly (i.e., without depending on an "automatic programming" environment (aka "a compiler") under the covers).
There will always be a need to translate natural language into logical language.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#404Earlier quoted context omitted.
Programs will write other programs, there is extensive work on this problem in progress with some nice low-hanging fruit available in research already. The future will need genius-level swengs only, all mundane/boilerplate/lookup tasks will be done by semi-automated systems and most swengs won't be needed anymore. I am working in this field and can clearly see where it goes and we finally have means to accomplish it…
We go through this once a decade. The problem is a fundamental byproduct of the disconnect between humans, to whom mathematics and logic are foreign concepts that take consistent work to internalize and apply, and machines, for whom ambiguity, context, and perspective are foreign concepts that take consistent work to "internalize" and apply. Call me a philistine, but I don't really believe we will ever get the natura…
The thing is there was enormous progress in natural language processing lately; it's now conceivable to enable some simpler forms of programming using your voice commands only (imagine webapp or mobile app builder controlled by voice) that would satisfy needs of 95% of population, putting many companies out of business. Even at top 5 companies there is a panic about it and many managers will tell you in private they personally think in 10 years there won't be many high-income sweng jobs unless you are in ML or related field, as they see demos from their research labs.
I guess we will see how this pans out in the end...
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#405Complexity isn't smart.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#406Earlier quoted context omitted.
I wish... I worked for many companies everyone wanted to get in, and am still approached by big 4 ones G/FB/AP/AM (no MS as I rejected their offer already). What I observed is that consistently the ones that move to the top are the ones that master the practice of appearance, backstabbing, instigating fear of "missing the train" in superiors, throwing peers under the bus when fitting, betraying trust, sensing and ada…
So you've never worked at those companies, and you are assuming what it's like to work there? And are you claiming you make 500% more than say a senior engineer at G/FB?Am?
I actually worked for better companies (with emotional attachment from developers), one top-end pioneering company that invited all developers at least once a year to Silicon Valley regardless of rank, and one in particular that refused G's acquisition multiple times and G was forced to make an alliance with it, and this company is loved by many at HN these days. Ranked higher on Glassdoor than G/FB, and more than 50% of departures to G returned back within a year, telling all of us it's not worth it. Also having friends at G expressing their jealousy at what I was working on that they could only dream about at G. Which is why I am targeted by those big 4 companies all the time, and couldn't care less.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#407Some really simple technical principles:
Explicit is better than implicit. All state is hard to reason about and debug. Code that doesn't have tests is brittle. Short code is better than long code and no code is better than both. Inheritance of implementation is hard to reason about.
Some technical advice:
Write comments about why you're doing something, not how. Write lots of comments. Check preconditions, especially nulls. Write explicit error messages for every failure: you'll be searching for them one day.
One non-technical thing:
Understanding the problem you're trying to solve is often better than any technical knowledge. Understand the business processes, the users and the people and you'll find you're vastly more effective.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#408There’s no universal criteria of code quality. The same source code can be terribly bad for one project, and 100% perfect for another one. Don’t just blindly trust what other people say or write about the subject, when possible ask them why they advice stuff.
Learn algorithms and Big-O just enough to pass job interviews, deeper understanding of these is nearly useless in practice, at least outside few narrow niches.
Learn to design and code safe and efficient multithreaded software. While not often asked on interviews, you’ll do that over and over again regardless on languages and platforms, because nearly all modern CPUs are multi-core.
Learn to use other people’s libraries and third-party tools. While their quality vary, good ones can save you tremendous amount of time. BTW, an IDE is one of these tools. Just don’t forget about costs (some might be too expensive for particular project) and licensing (some are GPL).
Don’t afraid to change jobs. Just that you’re working with nice people is not a good reason to stick to your employer. Make sure you learn new stuff, skills degrade over time as the industry moves to new technologies and platforms.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#409Earlier quoted context omitted.
Whenever you set out to write something, write it differently than last time you did it. It takes conscious effort and a lot of getting used to but actually stopping and thinking about alternative ways of doing something is a practice in itself. When you act on these thoughts, you're most definitely practicing, and quite probably improving. This approach scales from the tiniest pieces of code to whole systems. If you…
I don't know about doing this in a project you're being paid for, it certainly increases the cognitive load of reading a codebase where simple things are done differently all over the place. Four years in I'm hoping the OP has seen a pretty broad range of different styles and approaches and is now ready to hone their craft with smaller improvements, and is no longer struggling just to get something working so they no…
> it certainly increases the cognitive load of reading a codebase where simple things are done differently all over the place.
But simple things are being done differently anyway, all the time. There's too much variation in how you can code anything. The most trivial functions, like leftPad, can have dozens of implementations across a couple of projects - each as correct as the others, some abstracted, some inlined. Above a certain proficiency level, programmers are expected to intelligently recognize leftPad when they see it, even if it's called `frobnicate` and is implemented backwards (whatever that would look like). How can you expect programmers to do this without them going through a large set of sample implementations? Are they going to wake up some day to realize they got enlightened and now have no problems with dealing with leftPad in any of its many forms?
I find the argument of "increased cognitive load" entirely unconvincing. Yes, the code should be optimized for reading. But, as every writer knows, how you write depends on who are you addressing. In other words, it's both insulting and counterproductive to write your code as if your readers are bird-brains with severely damaged hippocampus. Your readers are professional programmers who know their craft - possibly better than you do - so have a little faith in them!
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#410Everyone'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…
> Everyone's code basically sucks, including yours. Which is why I'd say, unit-test your code, or TDD, or something. When you look at that crap months later, your mental model of how it all works has completely eroded, and only the test suite is left to preserve your expectations as they existed back then, preventing you from wasting a lot of time stepping on your own toes while you re-grok the big picture, if you ha…
I'm.just now getting to the point where I'm finding this necessary. Any resources you can point to for a beginner in testing (python)?