
What are some things you wish you knew when you started programming? - afable
https://www.quora.com/What-are-some-things-you-wish-you-knew-when-you-started-programming/answer/Ken-Mazaika?share=1
======
bgribble
Write 5 tests for a piece of code that you think is working but has no tests.
You will find at least 1 bug every time.

Staying at work longer won't help you produce more and better code. Sleep and
exercise will.

People who get angry about technical choices like what framework to use or
what coding style or how tightly to enforce rules will flame out. Don't be
that person.

If you think you need to rewrite it from scratch, think again. Look up
Chesterton's Fence.

~~~
brador
"Chesterton's fence is the principle that reforms should not be made until the
reasoning behind the existing state of affairs is understood."

 _In the matter of reforming things, as distinct from deforming them, there is
one plain and simple principle; a principle which will probably be called a
paradox. There exists in such a case a certain institution or law; let us say,
for the sake of simplicity, a fence or gate erected across a road. The more
modern type of reformer goes gaily up to it and says, "I don't see the use of
this; let us clear it away." To which the more intelligent type of reformer
will do well to answer: "If you don't see the use of it, I certainly won't let
you clear it away. Go away and think. Then, when you can come back and tell me
that you do see the use of it, I may allow you to destroy it."[1]_

Source - Wikipedia.

~~~
crazygringo
Chesterton's Fence is a great example of why code comments are critical.

If the code is doing something that isn't immediately obvious to a programmer
on a deadline, there should be comments explaining why it's there.

"Go away and think" just means the programmer who wrote it couldn't be
bothered to take a couple of minutes to be clear, resulting in later
programmers wasting hours or days (or worse) re-discovering the reason for
something in the first place.

~~~
btschaegg
A counterpoint to this is that the very reason to refactor code usually is
that it isn't understandable anymore. I'd rather read it in the way that you
shouldn't rewrite code for which you don't understand _the problem it 's
trying to solve_.

In my experience, that part is usually much easier, since you're working in
hindsight.

There's a great interview Peter Seibel did with Bernie Cosell[1], where Cosell
explains that his approach to debugging usually consisted in

a) understanding what a specific piece of code is _supposed_ to do and

b) rewriting it so it _actually would do it properly_.

Of course there's much to be said on when this approach is overkill and when
it isn't.

[1]:
[https://en.m.wikipedia.org/wiki/Coders_at_work](https://en.m.wikipedia.org/wiki/Coders_at_work)

------
kurtisdipo
1\. Learn to be criticised and to gain as much knowledge from that, as
possible.

2\. Learn to fail and feel good with that. And as above, to gain as much
knowledge from that, as possible.

3\. Learn to be confident enough to defend your solution.

4\. Read as many non stricly technical books related to programming as
possible. Ie. "The Pragmatic Programmer", "Rework", "Clean code", etc.

5\. Don't take your job too serious. If you worry about your code after hours,
stop! And if you can't, change your employer.

6\. Everyone makes mistakes. Just try to not repeat them.

------
watwut
I think that 5. and 10. are not as good advice as they sound. Not many people
are good teachers and if you try to learn with other, they will oftentimes
attempt to do all the work, especially thinking part, for you. If they already
know more, there is no way for you to match their speed and you end up just
doing what they dictate - worst possible way to learn. If you want to become
good, you need to spend time learning alone, when you can try out wrong path
for a few minutes, solve problems independently even if it is slower, make
mistakes and finding out by yourself.

It is different if people around you have good social skills on top of tech
skills, but many people are not like that. A contact with community is
important for motivation and having possibility to work with good quality
people is indispensable. However, much of important learning happens when they
are not in the room and they can not take control of keyboard and tell you
solutions to problems before you had the chance to think.

------
Kenji
"9\. Trying to understand everything is a lost cause. In the beginning, I
tried to chase down the “why” to every problem I encountered. This isn’t
necessary."

Nonsense. That is literally the worst advice you could give to an aspiring
programmer. It is precisely necessary to get to the bottom of your programming
problems and bugs, that's the stuff that increases your knowledge and lets you
understand systems deeply. Be curious! Track things down all the way to the OS
and the hardware! Recently, I just found an OS bug that negatively affected
the realtime performance of our controllers. Dig deep! Never write code based
on ignorance!

~~~
thealistra
Wanted to write exactly this. This is a hurtful advice.

------
kh_hk
Since I see no mention on wages (maybe OT) I will chime in:

Value your work, even if you think you are "still learning". I spent way too
much time on under-market salaries writing good code. I wish someone had told
me I could be earning 5x whilst still at uni.

~~~
phkahler
Correct. I thought that somehow getting that degree suddenly qualified someone
as a "real engineer". You're better once you've finnished, but your capability
is still on a continuum starting prior to your first class.

------
anon1253
Don't drop critical thinking and "hammock time" in favor of Agile. Some
problems require a bit of personal reflection, without it you can easily end
up building something atrocious, even while following all the "best
practices". I spend a couple of years at a SCRUM shop and all we did was
"finishing stories" without any regard for architecture. The technical debt
was truly stunning. These days I easily spend a day just thinking about the
problem before writing some code, which then still happens in a REPL-driven
style to allow for experimentation and feedback. Best of both worlds I think.
Also, most programming is actually fairly easy. Focus on the (business)
problem you want to tackle instead of the code. Code is ephemeral, the only
thing that matters is the business value and the user experience for getting
there.

------
jacquesm

      side effects are bad
    
      code should follow data
    
      it won't do what you intend until you've verified it
    
      solve the problems you have, not the ones you anticipate you will have

~~~
GhostVII
> side effects are bad

How are side effects an inherintly bad thing? They are pretty important in
many cases.

~~~
jacquesm
Side effects from functions that modify global state (or importing global
state elsewhere) are bad because they increase the complexity of a program in
a way that can very rapidly spiral out of control. The operation of a function
reading global state is no longer easily predictable and you'll be tracking
hard to replicate bugs.

Better to have a function rely entirely on its arguments and to output the
result as a return value.

Side effects that do things such as persisting data or producing output are -
for the most part - acceptable, if they are contained in such a way that you
move to as much of a 'functional' approach as soon as you can.

So reserve your side effects for the edge of your program, keep the rest as
side-effect free as you can.

Now that was a little long for a bullet point list hence the abbreviated
version.

------
arethuza
Although I had done some programming before, I always remember the first
lecture of the first year of the CS course I did where the lecturer basically
concentrated on the importance of KISS (i.e. Keep It Simple Stupid). He did
say that we'd probably not believe him, and of course we didn't as we were all
desperate to prove how awfully _clever_ we were. He did also say that if we
stuck at things long enough we'd probably come to share his view.

How I wished I'd manage to believe that bit of advice a bit earlier in my
career and saved a few projects from my zealous architectural astronautics.
Well, at least that's one lesson I did eventually learn.

~~~
throwaway23408
Can't agree with this one enough. I'm currently battling through a project
full of people that are too smart for their own good and too stupid to realise
it.

I had a huge argument today with someone that wanted to wrap a certain type of
higher order function ("foos") in another higher order function with a
particular name ("fooGenerator()") for the sole purpose of differentiating it
from a different kind of higher order function in the same file ("bars").

I lost the argument. It turns out using heading comments to seperate groups of
similar functions, or god forbid splitting up the 400 line file into multiple
smaller ones, is too confusing and prone to errors by maintainers ("What if
they put a new foo function in the section for bar functions!")

~~~
flamtap
I am learning that sometimes people try to defend their ideas by coming up
with ways to make their idea work. If accommodating the solution is more work
than actually implementing it, it might not be the right solution.

------
JCDenton2052
That unless you are in a pure code monkey position, programming is at most,
30% of the job and there is an array of skills that have nothing to do with
programming that when mastered, will give the impression that you are an
expert programmer.

~~~
indreklasn
I have some idea what you're hinting on but no entirely. Im in my 3rd year in
and have seen a lot of bullshiting. Should I just learn to start bullshiting?

~~~
JCDenton2052
Is everything other than programming, "bullshitting"? Far from it. I am
referring to a multifaceted spectrum of skills, no different than one every
other non-technical professional has to contend with. Linguistic skills,
logical fallacies (recognising other peoples' bullshit), arguing pro and
contra, team dynamics, business knowledge (if you're in line of business
software, which most of us will be in), testing (a science in itself)... and
yes, the softer skills such as marketing yourself and trying to present your
work in the best possible light.

I would also recommend learning how politics function in the workplace, if
only so you can defend yourself from other peoples' black magic.

------
Keyframe
This is what I've learned over the years (since 9/BASIC in 1989.)

1\. Number of active users of language matter more than the language itself.

1.a Fads come and go.

2\. Math matters.

3\. Elaborate design/architecture before programming is a waste of time.
Emphasis on elaborate, not architecture.

~~~
flamtap
On #3: Agreed. In my experience, every time someone comes up with some grand
design before writing any code, it's built on one or more assumptions about
the problem. Then work begins, and one or more of the assumptions inevitably
turn out to be incorrect and the whole design gets deflated.

------
samsonradu
Besides all the good technical advice already mentioned here I'd like to add
some things I find very important, as I'm watching over the career progress of
2 junior developers.

Take VERY good care of your mental and physical health. Do not overwork
yourself. It's a marathon and you will overcome most challenges with time and
discipline. You don't have to be a genius/prodigy.

Don't put too much pressure on yourself - and it's hard not to due to all the
praising of highly successful programmers - but nobody is an overnight
success.

Enjoy your time off.

------
thosemagicstars
How about: \- Its not about code, its about solving problems. \- Learn to cope
with change. Programming constantly changes, make sure to deal with it and
don't get your self stuck on one thing you can do. Pick the cherries out of
every programming language and frameworks out there. You're a C# guy? Do some
ruby, you ruby guy? Do some node. \- Don't give a shit about mainstream. Do
what works for you. But keep an open mind and consider every option, and
always try to investigate why stuff works a certain way. \- Dont freak out if
you're lost in new things. Its normal, fork repos, join groups, irc channels
get familiar with things. \- There is no end-game. If you think that you're
going to be finished in a couple of years you're wrong, there is aways shit
tons of new stuff to learn. \- Dont be a perfectionist, its gonna stall you
and make you never deliver. \- Always deploy, refactoring shit is easier when
you know what problem your code introduces, so don't optimize prematurely.

------
tgarma1234
That there is a huge amount of marketing hype that comes out of silicon valley
for languages, projects, etc. and for the most part you are wasting your time
to get too deeply immersed in any one thing.

------
manmal
"Let go of your emotions" is very superficial and not really doable with the
advice that is given.

We build emotions based on the truths we perceive. The only way to healthily
change emotions is to change those truths. If you feel very attached to your
work and flip out (fear, anger) if someone else finds an error in it - you
need to change the believe that something bad will happen to you when you make
mistakes. Nobody will hit you over the head * , nobody will laugh at you * ,
you will not lose your job or career * . You will not be worth less as a
person. You made a mistake because your brain is built in a way that allows
for errors, and so is every other human brain on this planet.

* Ok somebody might do these things to you. But you will cope, and other people will help you cope.

------
espeed
The true language of computing is mathematics, and its power and beauty are
masked to those who cannot speak it. Programming languages are powerful tools
for communicating ideas and encoding the _language of mathematics_. You can
use these tools to shovel bits around without understanding the language, but
you won't be able to see or say much unless you become fluent. Creative
expression comes with fluency, and fluency requires the perspective unlocked
through deep understanding. Becoming fluent in the language of math is the
rite of passage one must cross to receive its true potential.

[https://en.wikipedia.org/wiki/Mathematics](https://en.wikipedia.org/wiki/Mathematics)

~~~
__ddd__
Logic more so than mathematics. Mathematics as a means to achieve efficiency,
which is an afterthought most of the time. Most working programmers don't need
more than a basic understanding of algebra.

~~~
espeed
Logic is a form a mathematics, and understanding logic is essential. Indeed,
for many programmers, that's the extent of the math they know and use. And
that's what limits them. There is so much more.

~~~
__ddd__
Unless you're​ solving mathematical problems, how does math directly translate
to programming (ignoring efficiency)? I agree with the sentiment that the
connection is over-stated. Whenever I hear this argument, it feels like
reductive FP propaganda. I'm interested in FP, but not because "it's just
math". Sometimes it's nice to piggyback off of mathematics, and it's true that
a program is a sort of proof, but sometimes (most of the time) it's better to
not be so formal, and not be so academic.

Also, math and logic are obviously related, but logic is not "a form of
mathematics". If anything, mathematics is a form of logic.

------
dottedmag
I wish I knew back then that being an employee is not the only way to earn
money through programming.

~~~
crizzooo
Can you elaborate?

~~~
dottedmag
I spent my first 5 years after university as an employee because "everybody
has a job" and it never occurred to me that I might freelance or start my own
business.

Doubly pitiful because I didn't need that much income back then, and later it
became much more complicated to stop being employee due to higher cost of
living in a place I moved to and due to need to support the family.

------
poizan42
> 7\. You don’t need 5 monitors.

No, but more than one can work wonders for productivity if you are looking up
documentation while coding, so you don't have to constantly alt-tab and
forgetting where you were.

~~~
bshimmin
I think this one is really a horses-for-courses situation. For me, my current
setup of two 2560x1440 monitors plus a 15" laptop is absolutely optimal - I
can spread a load of stuff out everywhere, flip between a few spaces, and just
generally be super-productive. I can still be productive working from just the
laptop in a coffee shop, but I feel very constrained and find myself shuffling
windows around to get stuff done (even just writing an email whilst referring
to something else), and I generally don't like it and pine for my multiple
monitors, especially if I'm doing any sort of development work.

Other people seem to be able to be just as productive from a single monitor or
laptop, and tabbing between things is very much just part of their workflow -
I remember at one gig we bought a couple of displays for one dev and he never
even bothered plugging them in.

(I don't think anyone really "needs" five monitors, though.)

~~~
tsul
To chime in anecdotally as a one-screen guy, for me it’s all about being able
to unplug my laptop, switch locations, and not feel like my workflow’s
crippled. I don’t like feeling anchored to my desk, or even the office as a
whole.

------
draw_down
I wish I knew how unsavory a long-term career in tech would be. I wish I had
just tried to get rich instead.

------
shardinator
1\. Learn regex properly and thoroughly, in one go. Learning it incrementally,
will take a lot more time in the long run.

2\. Write code that works reasonably well, then refactor it to be
smart/elegant.

------
pipio21
For anything you want to learn in your life the best thing you should learn:

Learn from the Masters, do not seek advice in random people on Internet.

It is called "modeling". Pick your masters-mentors carefully.

For example we have people in my company that could do the work of tens or
hundreds of people just by themselves because:

-they are incredible experienced and smart. -they know regular expressions, know how to automate everything. -they understand good design, and understand people as well as computers.

Just living around this people you will start modeling them, and doing the
same they do.

But people also model bad behaviors just by proximity. Fat people use to have
friends that are fat, and family members that are fat. The same happens with
smokers or drug addicts. You pick from your surroundings subconsciously.

For example someone here recommends you to not use vim, use an IDE. Well , the
masters I know either use vim or emacs a lot. They can use other tools like
IDEs too, but instead of depending on someone else for automating the stuff
they need they use to make their own tools.

Remember that no big company like Microsoft, Apple or Google are going to make
your life easier for making your software multi platform for example, but for
your company it could be essential. On the contrary, if you only use their
tools your life will be miserable if you go against the interest of those
companies.

------
versteegen
Seek out well written projects and contribute to them, you'll learn far faster
the principles of good software than working alone or on badly written code.

Focus on maintainability above speed, terseness, or perfection. Worse is
better (<\-- it took me many years to truly understand this expression)

Your plans/thoughts on any matter are strictly inferior to your thinking after
putting it into practice, so do not plan too much. Instead, experiment.

~~~
GuB-42
I think there is value in working with poorly written code. You will learn all
the details of the language, because you will see many edge cases. You will
learn about all the bad ideas (aka anti-patterns) so that you can avoid them.
You will learn that comments are lies and that there are things that you can't
trust. And hopefully, you will learn how to turn bad code into good code
without introducing more bugs than you have fixed. If you end up coding for a
living, you are more likely to see really bad code than good code. Not only
because though budget cuts and the occasional mess up by incompetent coders,
but also because good code simply works, and there is no need to touch it.

I totally agree with the "experiment" part though. Everything you learn is
worthless unless you actually code something, preferably something useful.

On a more technical point, I think that terseness is undervalued. The first
rule of good code, for me, is "write short code". There are a few exceptions
but these are just that : exceptions.

~~~
versteegen
I was writing from my own regret. I feel that I learnt surprisingly little by
spending a decade rewriting badly written code. I should have found out what
encapsulation was years earlier. Sure, there are lessons there, but I think
you will pick most of them up anywhere; you're always exposed to code you
don't like.

I still value terseness highly, as in my opinion it's strongly correlated with
readability (though not at all when taken to extremes), but I very often have
to increase verbosity to increase maintainability. E.g. don't take shortcuts
that will leak through abstractions.

------
corduroy
If you can afford the time cost, type out the code you were going to
copy/paste from somewhere else. You'll get a better feel for what's happening
as you type, allowing you to assimilate style conventions in with the rest of
your codebase. The few typos you will likely make will force you to understand
how exactly the code achieves goal.

------
GlennS
1\. Don't stay in a job that makes you miserable.

2\. The design and specification stages of programming are not pointless
enterprise makework, they are genuinely useful.

When writing a program, make sure you understand what you're trying to achieve
in detail, and write a plan about you intend to do that.

If you don't know what you're trying to achieve (and by extension your
customer/client doesn't either), schedule in some research / exploration work
as the first part of your plan.

Once you have a better idea, redo your plan (and maybe your budget) and check
it with your customer/client.

3\. If something is going wrong, or you think something is going to go wrong,
it's much better to tell someone as early as possible. Even if it's your
fault, don't sit on your shame - get some help.

For example, if you're going to go over budget, you may be able to get some
more budget. Or you may be able to get some features cut.

------
sgift
Code coverage doesn't say anything - if it doesn't fulfill the requirements
it's useless.

------
m_fayer
The vendor's way of doing things is just one of many possible ways, the vendor
is often not right, the vendor often has their own agenda, the sky will not
open and smite me if I don't go the vendor's way.

------
kgilpin
You will write tests, because without them, you cannot refactor.

With them, you will be able to quickly and easily make your code better and
better, with much less risk of regression.

As a result, the initial implementation details of your code are not very
important, and you don't have to spend much time thinking about how the code
might evolve in the future (which is unknowable anyway).

PS Don't spent much time testing the internals of your code. Check that the
inputs and outputs are correct, as thoroughly as you can. Testing internals
actually makes refactoring harder.

------
sebastianconcpt
Smalltalk plus the book about patterns. That would have been a game changer.
It happened to me but years later and largely improved my coding quality on
all other tech stacks

~~~
jpster
>the book about patterns

Could you be more specific?

~~~
redrummr
I think he means Kent Beck's book.

------
forgottenacc57
Use an IDE, not VIM

~~~
59nadir
This advice is of such low caliber and so out of touch it's almost as if you
didn't even bother to open the submission before posting. It's practically
useless to anyone, especially when you don't even attempt to give some
motivation for it.

It's over-generalized, likely because you know only one thing or you've
developed into doing only one thing and for that one thing vim is the worse
choice.

~~~
forgottenacc57
No, it's so spot on and correct it does not need lengthy justification.

------
norswap
Quantity trumps quality: if you code a lot and keep your eye out of quality,
your style will improve.

As a perfectionnist, I had to learn this the hard way.

[https://blog.codinghorror.com/quantity-always-trumps-
quality...](https://blog.codinghorror.com/quantity-always-trumps-quality/)

------
noir_lord
If you are constantly turning work down keep raising your prices until you
have enough work to keep you busy.

~~~
crizzooo
What are you coding that you're receiving contracts for?

------
coldcode
That I would still be programming 35.5 years later. I would have quit and
gotten a PhD and then continued.

------
luigi23
Lurk GitHub repos for solutions that you've done some time ago. It could
clearly show what you've been doing correctly and what you could improve.
Then, if you see some place for improvement in some repo, make a pull request.
Great way to learn, period.

------
babayega2
Not waste much time learning all the trending programming languages of the
moment.

------
ahallock
I wish I had learned many programming paradigms; I only started experimenting
with functional programming a few years ago. Imperative/OOP dominated every
college course and book I read.

------
epalmer
Review how others write in your language by examining GitHub projects.

------
amelius
> What are some things you wish you knew when you started programming?

That the status of being a programmer would drop to subzero levels in the next
two decades :S

~~~
corduroy
Care to elaborate and/or provide supporting evidence?

------
nunez
How to write good tests. I love writing tests now that I know how to do so.
It's like flowcharting, but with code!

------
DougN7
The most important thing is not the code - it's the people that use the code.
The more it helps people, the more valuable it is.

------
NKCSS
I don't agree with 9.

I tend to want to know how _everything_ works; this let's me reason about
anything and it helps a lot when debugging.

~~~
Bat-fink
Personally, I've found that getting that just getting a book on the technology
as a resource accomplishes two things --

1) Read the first chapter to get a fair understanding of how the technology
works (recently getting them for both Spring security and Hibernate search
helped emensely) and;

2) A way to sanity check your stackexchange solution you'll inevitably refer
to.

------
losteverything
It's not like being a plumber or electrician where you learn once and can make
a living all your life

------
xyzzy4
When I was younger I used to not know the benefits of hash maps and used
arrays for almost everything.

------
11thEarlOfMar
That if I stopped, it would be 20 years before I'd be able to start again.

------
second0
the moment I discovered how to use for( $i = 0; $i < 100 ; $++) that was quite
a moment, how to use loops properly was something I wished I knew earlier.

------
mleg
Have anyone already said English?

------
mleg
Anyone already said English?

------
tluyben2
Read more code.

------
vasira
Write codes more and more and try to be creative

