
Advice to new programmers - ingve
http://olafurw.com/2019-01-27-programmer-advice/
======
sephoric
I love the simple software-centric approach to analyzing this survey and
categorizing the answers.

There's one thing I'm sure was mentioned a lot by 17.1% of the participants,
but it's one thing I'd like to stress:

Find a good mentor!

I've been teaching my son programming steadily for a few years now, and every
so often he likes to take what he just learned, go and revisit some old
programs he wrote or read from before he understood the new concept, and
understand it better and often improve on it a lot (even rewriting it
sometimes), and then he comes back to me very excitedly telling me how the new
concept I taught him greatly improved the thing he did.

He's already writing code better than I did when I was a decade older than
him, easily grasping new concepts like linked lists, garbage collection,
pointers, and Lua coroutines and so on. When I was his age, I was still
struggling to understand arrays in QBasic, had nobody to mentor and guide and
teach me, and was generally pretty lost. Having a mentor who can guide you
carefully and at your pace is an incredibly powerful shortcut.

~~~
austincheney
The need of mentoring must be completely voluntary. I was hired to be a team
senior of developers who didn’t think they needed a mentor and it didn’t work
out so well.

People actively seeking a mentor are likely willing to consider the advice and
tough criticism they get as points to self-reflect upon, because they want to
improve. They want to become faster stronger developers. As common as that
might sound I have found intentional yearning for self-improvement to be rare
or severely misunderstood among junior developers in the corporate world. More
common than self improvement is interest in specific technology stacks of the
moment and persuit of near instant gratification.

EDIT

Actually, I can remember observing this behavior once as a junior developer.
When I started learning JavaScript 12 years ago the real big deal then was
Java. Compared to me at the time everybody seemed incredibly experienced and
talented, but most of the developers were negligent to the point of horrid
incompetence at the frontend skills even though this was a big brand web
business and 90% of their efforts generated frontend code.

There were a few Java developers who did have a solid understanding of the
frontend code, but they intentionally didn’t advertise this. I had to actively
observe for it. After badgering some of these people it was clear they were
willing to provide mentoring if I asked for it and worked my ass off to chase
it.

What I learned the hard way is the people who made the best developers had a
secondary skill they actively thought about more than their primary skill and
used that to reinforce their primary skill. At first it was Java developers
who had a solid grasp of things like CSS, but I also saw it in others who were
working out product management skills or business pricing logic more related
to finance than programming. These people also tended to make strong mentors.
The people focused on only their primary skills weren’t as capable and didn’t
seek mentoring themselves or have much to offer other junior developers.

~~~
mikekchar
On that topic, if you are the most senior person on the team and the other
members don't seem like they want mentoring, my biggest piece of advice is to
wait. Sometimes it feels like you are waiting forever (and with some people
you will be). Mentoring is as much about trust as it is about passing over
knowledge. You can imagine the people you will potentially mentor as wild
animals. Even if you have gobs of yummy food on hand, they won't be ready to
take it from you at first. The trick is to stand still, keep your calm and
keep offering small little treats. Eventually one or two of them will come by
and take a nibble. Don't pounce on them. Just stay calm and keep offering
treats. Eventually some of them will come to trust you well enough to eat a
whole meal from you. Some never will. That's just the way it is.

~~~
austincheney
In front end development trust is universally near absent. People are wanting
instant gratification and there is huge peer pressure to concede that a tool
or framework will solve all your problems for you. _Invented here syndrome_ is
the name of the game. They don’t trust themselves or each other. It really
feels that for most frontend developers it really is all about tools and
trends until they spinoff into another career path or promote out.

I do agree that trust is huge for mentoring.

~~~
mikekchar
I'm not sure about typical front end development culture (the front end devs
we have on our team are really very good), but I have been very surprised
about how this generation of programmers in general choose to trust people and
code. To be fair, it might just be some of the people I've met, but as an old
guy, it seems to be more prevalent than I've ever seen before. I find that
younger devs are prone to trusting code written by people they've never met
before. If it's popular on the internet, it seems that it must be good. On the
other hand, they seem to be _very_ cautious about code they get from their
colleagues. As you say, _invented here syndrome_. It seems like if the code
was written by someone they know, then it can't be any good.

But I think a lot of that is a lack of confidence and experience. It's hard to
talk about this without sounding like a gigantic ass because no matter how I
put this, I can't find a way to express how much I really respect other
developers. However, I've noticed that there seems to be a big reluctance for
actually reading and appreciating the code in the tools people use -- almost
as if there is some magic seal on the code and despite it being open source,
we are not worthy to gaze upon the code. I think there is a fairly large
amount of hero worship going on and a kind of herd mentality. To question the
laws that were handed down from on high is blasphemous (almost literally). It
is to the point where many people feel that they are transgressing badly if
they even deviate from the "community approved" coding standards. Thank god
for auto-reformatting tools is all I can say!

When these same people see their colleagues, they realise that it's just some
other goofball like themselves. Their colleagues are struggling, making
mistakes, rewriting, grinding away. So I think there is a kind of group
impostor syndrome going on where they think, "Well, that guy isn't that much
better than me and I suck!" What they don't realise is that their heroes in
the FANG companies and their nameless horde of community members are just
goofballs too -- struggling, making mistakes, grinding away.

I think as well, we often see projects and people fall from grace. Some
project grinds to a halt, or the horrible problems it's had from the start
become more obvious to the horde. And then all of a sudden it's, "That guy is
a joke. Only morons would use that framework. All the cool people have moved
over to <some other equally flawed thing>". But again, I think it's just part
and parcel of a lack of experience and confidence. Most young devs are
secretly, desperately hoping that somebody out there knows "how to do it
right". They get disillusioned quickly when they discover that their heroes
don't know how to do it right.

And of course, nobody does ;-) But that's a hard message to sell.

~~~
austincheney
As a side story to your wonderful comment I had a colleague recommend I use a
different IDE at work because their favorite code beautification tool was only
available in one editor at the time. They didn't realize I am a contributor on
the project they were promoting or that one of the code beautifiers in that
project was mine. The team on this tool were actively working on diversifying
to various IDEs but just hadn't gotten there quite yet. That was an awkward
moment.

~~~
richardhod
I'm curious: how was that awkward, rather than hilarious or glorious?!

~~~
mixmastamyk
Right, we weren't there but from the description it seems like serendipity.

------
RealityVoid
I have a problem. I try to be as helpful as possible. But when deadlines are
near(and that seems to be constant lately) I lose my patience. I lose patience
when juniors ask things they could have easily searched. I lose my patience
when they come to me going "this isn't working" without having tried any
alternative. I lose my patience when they ask me for things I could not know,
that they should know and all I do to solve the problem is just probe a bit
more.

So how do you, who are comparatively more experienced than your peers, not
lose your patience?

EDIT: replaced 5x instances of loose with lose. Oh god. I was kinda' drunk and
would be tempted to blame auto-correct on my mobile device but I just tried
it, and it doesn't turn lose into loose. So I must just be a idiot.

~~~
rafiki6
I've learned that there are certain skills that separate good developers from
mediocre ones, and that's 3 main things 1) curiosity 2) Grit 3) Patience

Curiosity is having a problem and caring about finding out why it isn't
working. Grit is having the resolve to keep chipping away at the problem until
it's solved. Patience is realizing that things take time.

Whenever a junior starts asking me things when I'm on a deadline, I politely
tell them to "keep looking". I'll potentially provide a hint if it will help.
Some get annoyed and scoff at me and tell me "I've been searching!". Others
keep looking.

~~~
celticninja
in that situation perhaps you could review their keywords. I know that
sometimes the solution can be found through searching, but knowing what to
search is half the battle. Reviewing their search terms and suggesting
alternatives should take very little time and helps them keep searching and
gets them off your back for a little while. It is also not as dismissive as
'keep searching'

~~~
rafiki6
I have tried that strategy but many people get offended when you question
their googlefoo.

------
tzhenghao
All very good and important advice for those entering the industry. I'd like
to stress the people aspect even more. Treat people the way you want to be
treated. If an engineer doesn't understand a certain technology, kindly
explain it to them instead of berating them for being "not smart". The jerks
will outnumber the saints, but being the latter almost always pay off (being
successful, high status, generally liked by everyone else etc.) in the long
run.

~~~
Consultant32452
I'll second this with my anecdata. The thing that has always made me the most
money is being able to communicate technical things to non-technical people in
a way that doesn't make them feel stupid. There is usually at least one better
coder than me on any given team, but they never get advancement because they
can only talk to other engineers who they are also usually talking down to.

------
apl002
As a somewhat still new and self taught programmer, the "dont compare yourself
to others, but where you were in the past" really resonates with me.

I've come a really long way and I'm proud of how far I've come. At the same
time I definitely have moments where I interact with someone else and think
I'm still such a novice. I am much better at when this happens, being ok with
it being true and using it as motivation to keep learning and get better.

~~~
WrtCdEvrydy
I'm gonna give you a secret... this will make your career easy... listen.

'The more you learn, the less you know'.

Now say it to yourself.

~~~
james_s_tayler
Totally. Something I learned very early on was your big idea isn't as big or
clever as you think (necessarily, but sometimes it is!), so it's worthwhile to
canvas the office to first find out the history of why something is the way it
is or why we don't currently do X.

Often you find it used to be done that way in the past and then they stopped
doing it that way because Y. It turns up all kinds of interesting stuff that
no amount of thinking will get you to on your own.

That would be my number one advice for those starting out.

------
ChucklesNorris
These replies were not what I expected. Practice, practice, practice is not
necessarily good advice if you don't know what you're doing. Before I took
college programming classes I was self taught and wrote what I later learned
was called "spaghetti code." I had no idea (before the classes) who was giving
me good advice and who was giving me bad advice. My code was unorganized and a
total mess.

In my class, our textbook was "The Elements Of Programming Style" by Kernighan
and Plaugher. As far as I'm concerned, it is THE book for beginning
programmers. It's rare and expensive now, but worth it.

In a nutshell, it taught:

\- program in a direct way, do NOT try to be clever and code in weird, complex
ways. Your code (not just the comments) needs to be readable to others, what
it does should be evident. (The book gave examples of both, and after looking
at a number of these examples, you get the idea of what K&P mean by ELEGANT
programming.)

\- Subroutines must have one entry point and one exit point, and accomplish
one task.

\- Add lots of comments in your code to help others or even yourself in case
you forget what your thinking was.

These are just a few examples of good programming practice. I later became a
professional programmer, using assembly language and C++. But that first
college book was the one that outshone all the later ones that I read. Get it
if you can find it!

I would also highly recommend Dennis Ritchie's books.

One more thing - object oriented programming is good, but I'm not sure it's
paradigm will win out in the end. As an assembly language programmer, I began
to realize the power of data driven programming, and I began to write my
programs in that way. Which is why I think this new language, Julia, holds a
lot of promise. I say this as one who has only read ABOUT Julia, not as one
who has studied the language itself.

~~~
V-2
_> \- Subroutines must have one entry point and one exit point, and accomplish
one task._

Sometimes code is much cleaner if you exit a method or a function early.
Especially in languages with automatic memory management where you don't need
to concern yourself about leaks so much.

 _> \- Add lots of comments in your code to help others or even yourself in
case you forget what your thinking was._

Lots of comments is a red flag to me. It often indicates the code itself is of
poor readability. But it's usually easier to just slap some comment on it than
to properly rewrite it... "A comment is a failure to express yourself in code"
(Uncle Bob).

 _> These are just a few examples of good programming practice_

I'd argue they are debatable, and at the very least not necessarily universal.

~~~
HereBeBeasties
Ah, the most important rule - there are no rules, only compromises.

------
pnevares
The overwhelming majority of these points are useful, and the exact thing that
"engineering culture" Twitter has been excelling at for a while now. It wasn't
always easy to find people supporting people at every stage of their career,
but there are several accounts to follow to do just that.

The "one page ahead in the manual" quote is a great example of this. It's hard
to remember when you didn't know everything you know today -- so think about
yesterday, or last week, some smaller time slice. What did you learn yesterday
that somebody on your team may not know? Operating at that layer and sharing
knowledge freely shows you're a friendly resource and shows that you're honest
about your journey. It attracts other people who are slightly above or below
that level, who can share and multiply what you're learning.

(And it has a great byproduct of teaching you where the egos sit at your
company.)

------
wilkskyes
My advice would be to learn and master vim.

When I began programming, I was forced to use vim and hated it, I didn't
understand why someone would use such an "old school" text editor to write
programs. I abandoned it and moved on to typical IDEs. As a young programmer,
it's difficult to see the value.

But many years later I discovered the power of vim came from customizing it to
my exact preferences, and mastering all the shortcuts and its grammar. After a
year's worth of effort, I began coding at the speed of thought, and
programming has been much more enjoyable ever since, as time moves on I only
get faster and faster. It's like cooking with a really sharp knife vs a dull
one.

~~~
jrs95
This somewhat depends on the technology you're using as well though. Writing
Java in vim is a pain in the ass in comparison to something like IntelliJ that
has auto-importing, go to definition, etc

~~~
wilkskyes
You can do all those things with vim. Look it up.

------
Blinks-
I posted something similar in another thread about advice but take a
programming 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. This can be
especially helpful with network stack and TCP/IP related work, remembering all
the acronyms can save you a lot of time.

------
tskubicki
More on the "growing your career" side:

Build something that solves a problem and put it on github.

Not only are you adding to your portfolio, but you're demonstrating that you
can take a problem and come up with a solution for it. Canned "To Do" apps
aren't as impactful because there's a 1000 tutorials for this online and
everyone knows it (though they can still help for showing knowledge of a
technology or stack, so don't count them out)

~~~
wincy
This is how I broke into my first full time dev job from tech support. I wrote
a web page without any frameworks or anything that would upload images,
remember the hashes for them, rotate them, and detect duplicates. I built it
because I didn’t want my daughters pictures on Facebook but wanted to share
images with family. Then I made a YouTube video with lots of pictures of pizza
to demo it. The hardest part for sure as a dev learning only from my Google fu
was the async stuff. But I doubled my income that year, so it was definitely
worth it.

------
scaryclam
Be humble. Be kind. Remember you're never as senior as you think you are.
Opposing opinions are not wrong. Remember to have fun, because building things
is awesome. Tomorrow is an opportunity to be better.

~~~
jrs95
I wouldn't necessarily say that opposing opinions aren't wrong. Sometimes they
are, and a lot of the time it's because of some form of institutional inertia.
In general though, you'll have great ideas, people will politely tell you to
fuck off, and you have to be able to get over it quickly or you'll make
yourself hate your job.

------
Jach
A quote from _why is something I'm occasionally reminded of, and still
struggle with sometimes even though my first lick of programming was 15 years
ago:

"When you don't create things, you become defined by your tastes rather than
ability. Your tastes only narrow & exclude people. So create."

------
edoo
Some good advice on there. I like the no shortcuts one. Another way to put it
is the longest way is the shortest way. If you think you are taking a short
cut you are likely taking a long cut overall.

~~~
knodi123
I learned SO much about windows during the 2 weeks when my mouse was broken
and I was too cheap to replace it. Turns out you can do pretty much anything
without the mouse, even without turning on handicapped assistive mode!

And there was a time when a snotty admin convinced me that he had the
authority to require me to do development in vim. He did not, and damn that
learning curve was steep- but I picked up skills that still serve me well a
couple decades later.

Oh, and another one - we had a process for cranking out custom reports, where
if you could express the entire thing they were asking for in SQL, then you
were done. But if any part of required programming logic, you had to create a
controller, and a template file, and register them, and do a full product
release... it was a big hassle. And man did I ever learn how to make SQL jump
through hoops at that job.

So, a corollary to your "The longest way is the shortest way" is my life
lesson - Constraints make you better.

~~~
edoo
I like that. A constraint means you have at least a starting point too. I've
always struggled to keep on track when faced with seemingly infinite options.
The first few decisions/constraints that define a project and allow it to be
worked on can take a long time.

I really wonder if that admin was more of a 'bastard operator from hell' (old
school reference) or sneakily getting you to improve yourself.

~~~
knodi123
> I really wonder if that admin was more of a 'bastard operator from hell'

Ha, yes, he absolutely was. Just very lazy, knew I already had SSH access to
our staging server, and knew I needed to develop on there, but didn't want to
bother setting up SSHFS and configuring it to be accessible from my windows
machine, and didn't want me telling him to do a new staging deploy every 10
minutes while I tried to figure out how to get some connected hardware working
right.

------
ohiovr
I have learned that I have peak efficiency in code in the early morning and
stays strong for 6 hours. By 8 hours I start getting hung up on simpler
problems and it’s just a waste of time to keep on going. Take time to relax
and sleep. You will have the answer to your problem sometimes just minutes
from wake.

------
wslh
A side note: next time you want to scrape Twitter use
[https://github.com/twintproject/twint](https://github.com/twintproject/twint)
which is relatively faster and use some tricks to avoid scraping defense
techniques.

------
_mrmnmly
Ah sir, you could just ask me directly [https://lukaszkups.net/notes/tips-for-
beginner-programmers/](https://lukaszkups.net/notes/tips-for-beginner-
programmers/) ;)

------
pjmlp
Love the advices, many of them resonate to me as well, thanks for sharing.

------
adamnemecek
Pick your favorite open source project, fire up debugger and start hacking.

~~~
aliswe
This one is pretty close to what my advice would be. I started out making
games at 9 yo, using clickteams klik&play, tgf, and later mmf and mmf2. (They
were the creators of amos & stos although that was before my time)

For those unfamiliar with the development experience, its very similar to
scratch but with a spreadsheet-like layout.

When I seriously started learning the workings of more complex logic in these
tools is when I started reading the "source code" of the 2d platformer Zeb,
programmed by Lee Bamber (who would later go out to make Dark Basic), drawn by
Nolan Worthington.

This taught me in a very condensed manner lots of advanced programming
techniques. Like a teacher of mine used to say, this will feel like drinking
Fun Light (concentrated drink supposed to be cut like 1/12) directly out of
the bottle.

And that tradition has stuck with me, decompiling dlls and inspecting websites
etc.

