4 ms·

Ask HN: As a programmer, what do you wish you knew at 25?

6 points by FahadUddin92 8y ago

What have you learned now that you wish when you started?

MrEfficiency 8y ago
Here are some >Yes I am a programmer, stop questioning it >Stop avoiding learning to make macros and job automation, it will pay dividends >Javascript is fine, not great. >Embedded systems should be my full-time hobby >Stop avoiding capitalism and start charging money for my otherwise free products.
avip 8y ago
The most important take, which took me years to sink in, is that code does not matter. So many things stem from that simple fact.
- FahadUddin92 8y ago
  Huh? What do you mean?
krapp 8y ago
To stop being obsessed with pointless BS and actually finish something. Even if it's terrible. Also, that I would deeply regret going to school to learn progamming once Udemy became a thing.
- lnalx 8y ago
  > To stop being obsessed with pointless BS and actually finish something. Even if it's terrible. Can you go deeper ?
  - krapp 8y ago
    Once my projects get complex enough, I have a habit of wanting to dump everything and start over or else get sidetracked by tangents. For instance, in trying to get my second game project finished (cloning Berzerk) I got a decent bit of the way there but decided I hated everything. I've since deleted and rewrote the ECS at least three times, added, deleted and readded a Lua API (which I actually like but wasn't really necessary), wrote and rewrote a font atlas for SDL's font library (again, fun, but not necessary), and am currently on my whatever-th complete rewrite of the engine because I decided it needs to be redesigned around sparse arrays and not vectors of pointers. So in the end I have piles of half-baked ideas and unimplemented code and nothing finished. Turns out I like the code I don't write more than the code I do.
vjsc 8y ago
I wish I knew at 25 that programming is perhaps not my actual calling.
makecheck 8y ago
The most carefully-constructed, architecturally-pure piece of code will still break in the face of future requirements. And in a surprising number of cases, it will break on the very first new requirement. Keep it straightforward and get it done. You will almost never be working on something so performance-critical that it truly needs cleverness and super-optimization. And you will rarely have time to properly measure a particular thing anyway. You will be expected to frequently change things and super-optimal code is a pain to modify. You will work with programmers with a variety of skills and it will often be impossible for them to maintain things of moderate complexity. Or, your team will be using ancient tool versions that can’t reliably do the spiffy new thing in the language. Again, straightforward code wins. When you write a test, first set up a case that fails to make sure your test can actually catch a failure. Too much time is spent debugging things because tests “pass” when the tests themselves just weren’t doing what they meant to do. The code is king: put everything you possibly can in there (comments, etc.). Don’t let people set up external documentation that no one reads, because it becomes wrong/misleading within a day. If you must have things outside the code, they need to be revision-controlled alongside the code, in the same repository.

6 points by FahadUddin92 8y ago

What have you learned now that you wish when you started?

Here are some >Yes I am a programmer, stop questioning it >Stop avoiding learning to make macros and job automation, it will pay dividends >Javascript is fine, not great. >Embedded systems should be my full-time hobby >Stop avoiding capitalism and start charging money for my otherwise free products.

avip 8y ago

The most important take, which took me years to sink in, is that code does not matter. So many things stem from that simple fact.

FahadUddin92 8y ago
Huh? What do you mean?

krapp 8y ago

To stop being obsessed with pointless BS and actually finish something. Even if it's terrible. Also, that I would deeply regret going to school to learn progamming once Udemy became a thing.

lnalx 8y ago
> To stop being obsessed with pointless BS and actually finish something. Even if it's terrible. Can you go deeper ?
- krapp 8y ago
  Once my projects get complex enough, I have a habit of wanting to dump everything and start over or else get sidetracked by tangents. For instance, in trying to get my second game project finished (cloning Berzerk) I got a decent bit of the way there but decided I hated everything. I've since deleted and rewrote the ECS at least three times, added, deleted and readded a Lua API (which I actually like but wasn't really necessary), wrote and rewrote a font atlas for SDL's font library (again, fun, but not necessary), and am currently on my whatever-th complete rewrite of the engine because I decided it needs to be redesigned around sparse arrays and not vectors of pointers. So in the end I have piles of half-baked ideas and unimplemented code and nothing finished. Turns out I like the code I don't write more than the code I do.

vjsc 8y ago

I wish I knew at 25 that programming is perhaps not my actual calling.

makecheck 8y ago

The most carefully-constructed, architecturally-pure piece of code will still break in the face of future requirements. And in a surprising number of cases, it will break on the very first new requirement. Keep it straightforward and get it done. You will almost never be working on something so performance-critical that it truly needs cleverness and super-optimization. And you will rarely have time to properly measure a particular thing anyway. You will be expected to frequently change things and super-optimal code is a pain to modify. You will work with programmers with a variety of skills and it will often be impossible for them to maintain things of moderate complexity. Or, your team will be using ancient tool versions that can’t reliably do the spiffy new thing in the language. Again, straightforward code wins. When you write a test, first set up a case that fails to make sure your test can actually catch a failure. Too much time is spent debugging things because tests “pass” when the tests themselves just weren’t doing what they meant to do. The code is king: put everything you possibly can in there (comments, etc.). Don’t let people set up external documentation that no one reads, because it becomes wrong/misleading within a day. If you must have things outside the code, they need to be revision-controlled alongside the code, in the same repository.