I inquired about this to a friend of mine who was mostly self taught at first, he has now past the 10 years experience mark but is just finishing up school in between freelance jobs. One of the things he told me was to take a terminology/vocabulary class, you probably know most of it after a few years experience but even a slight misunderstanding in diction can have serious implications down the line. I was surprised how much I learned and how beneficial it was to the conciseness of my code comments.
Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
411–420 of 538 posts
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#412Work 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 worked in the IT department of an early software company (est. 1980) based in the Bay area.
It was slightly better, since people understood software's value, and Ops was shared between the devs and IT. However, maintaining that sort of culture always felt like a constant battle. Management often slipped into IT = cost center.
In fact, my job officially became bridging this gap as an IT Business Partner. I don't think I did a very good job.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#413Everyone'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…
> 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. This is really untrue. On the surface, code might look the same between a beginner and a senior developer, but the decisions underlying the code will be night and day. Beginners will solve the problem of the day directly, with no care for introducing comple…
Probably unrelated
It pisses me off how I keep having to rewrite/resolve this particular problem I have of deploying a photo sharing site based in a poor network area.
One day I feel satisfied with the work I've just done, the next day it is garbage and I do it again a different way.
Faster but not fast enough.
Then you get this huge block of code and feel this heavy weight like ahhh.... Slash and burn...
Am I doing this the right way? What is the right way? Look at other major sites, why don't I achieve that same performance?
It is nicer to start over but is it a waste?
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#414Everyone'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…
That seems like a lesson in corporate culture, not programming. Nothing that you do really matters more than how good you look doing it?
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#415Earlier quoted context omitted.
There's a balance to be struck there, though, and pejoratively referring to the seeking out of ways to improve as "CV driven programming" probably isn't the healthiest attitude out there. If you're not doing new things, you run a very great risk of sitting in a weak local maximum. Don't fix what isn't broken--but you need to be stretching out, too. Not doing so induces a sense of stagnation to a team and can chase of…
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…
There are plenty of cases where new frameworks come out that allow you to move forward much more rapidly as a dev team. They allow better testing, better code organization, etc.
Especially in the Javascript world, it's such a new field that new techniques are being invented regularly. I've seen old backbone applications that are essentially frozen in time feature wise, because the code is so cumbersome and coupled together (by the framework's design) that it becomes impossible to add new features without having to refactor/rewrite the entire thing.
I agree, if you have have a finished product that won't be getting many new features at all, then leave it alone. But if it is an ever evolving product with new use-cases and features being dreamed up regularly, that application should probably be re-written many times over.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#416I was kind of shocked at the discrepancy between the reality of working as a programmer at a small company and what one learns about how to "do things right the right way" - version control system? What is that? Automated testing? Or even systematic testing? No time, we have to ship the next release! Using global variables sparingly? - Hysterical laughter The important lesson for me was not to despair and not to get…
Do you use source control just for yourself? How do you keep sane?
At work, I used RCS, because it was the lowest-maintenance solution I knew of at the time.
After leaving that company, I eventually discovered mercurial, and later fossil.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#417Earlier quoted context omitted.
This. Make your _business_ case, not a technical case. This applies to software engineering, security engineering, etc. The above comment does not absolve you from doing cool things, it's just that the cool things should align with business interests. No yak shaving. Sometimes writing a one-off script will take 30 minutes, and doing it by hand will take 10. Do it by hand.
Here's my problem. I'm not particularly prolific, so the number of ideas I have far outweighs my execution so far. This is mostly due to ADHD and other issues which I'm working on fixing, and while contextually relevant is not my point. This lack of prolific-ness means that I have a literal tower (it's rather intimidating) of wanting to build cute but objectively not so useful routines simply for the sake of building…
Personally written organization helps me. I like to use Trello to organize my thoughts. When you get an idea, write a quick note to get it out of your head so you can stop thinking about it. It's written down, you now have the freedom to let go and attend to it later. Schedule specific time to look at that list and put it on your Calendar so you don't forget. "I don't need to think about that right now, I made time on Sunday afternoon to prioritize and pick out which ideas are worth it." or "I will only check my ideas for things to refactor when I have a lull in my schedule, but I'm busy right now."
Also on the tower of ideas-- it's not a to-do list, you don't have to commit to every idea that flies through your head. Your ideas are a great resource for you to reach for any time you need it. A lake of ideas you only need to go fishing in when you happen to want to.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#418Everyone'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…
TDD seems to be mentioned in a lot of responses here. I'm warming up to the idea but frankly not many folks I've come across in my (short, 3 year) career seem to understand tests really, definitely not TDD. So I've been having to learn the hard way.
My main thing with TDD right now is - how do I avoid writing tests that are too tightly coupled? I've gotten burned in the past, not even doing TDD, with tests that "know too much" and end up being more hassle than help.
Any good resources on TDD and general testing strategy that anyone can recommend?
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#419The most important lessons in coding have little to do with coding and a lot to do with people - code is written for people not the computer.
The more you know the more you will come to understand you don't know much; that is both good and bad (Dunning Kruger vs Imposter Syndrome).
Every time you think you are the best in the room, look around and ask yourself are you overestimating your knowledge. If you are still the best in the room, maybe it is time to find a room with smarter people.
Not every solution requires code / technology.
The best code is easy to read and even easier to delete.
Give your code to the most junior member of your team - if they struggle with it you need to make it simpler.
There are many many lessons like these around - the single most important one - always be open to new ideas no matter how much they oppose your current beliefs; strong opinions, weakly held.
Re: Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?
#420The most important lessons in coding have little to do with coding and a lot to do with people - code is written for people not the computer.
The more you know the more you will come to understand you don't know much; that is both good and bad (Dunning Kruger vs Imposter Syndrome).
Every time you think you are the best in the room, look around and ask yourself are you overestimating your knowledge. If you are still the best in the room, maybe it is time to find a room with smarter people.
Not every solution requires code / technology.
The best code is easy to read and even easier to delete.
Give your code to the most junior member of your team - if they struggle with it you need to make it simpler.
There are many many lessons like these around - the single most important one - always be open to new ideas no matter how much they oppose your current beliefs; strong opinions, weakly held.