
I have no idea what I’m doing but I’m a programmer - squixy
https://blog.lelonek.me/i-have-no-idea-what-i-m-doing-but-i-m-a-programmer-d263dbcd024f
======
tyingq
The author is a few years out of college, with work experience that consists
of a bunch of short term (3-4 months) projects with wildly different roles (EE
java, iOS, Android, Scala, Ruby).

His blog posts all seem to follow a pattern of "bad things" he observes others
doing, and what his advice is. His experience level seems a little light to be
writing with that kind of tone.

That said, he does seem to have experience with a wide array of different
platforms, client companies, etc.

I think he would get more people to pay attention if he would post something
based on those experiences. Or, if it's going to be a "this is bad, do this
instead" post, use your own experience...something you started doing badly
yourself and then recovered from.

~~~
TeMPOraL
It may be just that stage in developer's life ;). A mark of a youngster.

I remember when I was 3-4 years into programming, I used to rant about style
and best practices too. I now look back at it as evidence of my lack of
experience (writing tone, especially, is a good indicator of it), but I did
learn hell of a lot by writing those walls of text. There's something about
writing things down in a coherent form that solidifies thoughts.

~~~
zamalek
Experience cannot replace enthusiasm.

The one junior in our office is _fresh_ out of university. He's in the team
that does all the difficult stuff. Most of all, he's incredibly green.
However, he's constantly listening, and attempting to contribute, to
conversations between the "sages" in the office. In a few months he has become
more senior than many of the people who have been working there for _years._

I'd much rather work with someone like Kamil than that vitriolic "expert" on
Reddit who claims you need 15+ years before you are able to think about your
job.

~~~
mercer
The people I most fondly remember working with somehow managed to become
really good while keeping all the good parts of being juniors.

At one company I worked for, there was one guy, a kid, really, the youngest
person on the team, who was approached by _everyone_ for help. No matter
whether the problem was front-end javascript, back-end python, something to do
with algorithms or a difficult regex, he could instantly switch context and
help out. And if he couldn't help, he'd come over a few hours later with a
better solution than you had thought up in the interim.

And yet, he was ever humble, smiling, and never seemed bothered by being
interrupted. He didn't make you feel like you were stupid while at the same
time giving you a solution and properly explaining it. Never mind that he was
half your age, it never felt humiliating.

He's the kind of programmer I aspire to become, both in skill and attitude,
and I wish there were more like him around.

------
taurath
The primary emphasis of this article seems to be: "Stop playing with code and
start reading books". Reading a book is a great way to get a lot of
theoretical knowledge but mapping it to a real problem or solution is what
causes the knowledge to stick. Programmers have to balance theory and usage to
do well.

You can't learn to be an artist by studying everything about paintbrushes
first. Certainly you could, but it won't help you understand the motions to
paint. At the same time randomly using any brush that can barely work probably
won't get you the results you want. I hope the author someday realizes that
almost everything is a continuum. Lamenting that "programmers of today" don't
read enough books doesn't really tell you much - only that he wishes the
people he see's would think more about theory.

~~~
peruvian
A lot of newbies get stuck in what I call a "tutorial loop": They finish some
mediocre/hand-holding tutorial, but they don't feel like they can write
anything yet, so they go to another one, and another one, etc. They never end
up building anything because they preoccupied with being "ready" before doing
anything.

I say, stop reading tutorials, hit up the documentation/IRC, and build
something. Won't be easy but that's how you learn!

~~~
sdrothrock
I encounter the same thing when people try to learn to study Japanese -- they
keep dancing around it by reading about how other people learned/studied,
weighing the pros/cons of various approaches and textbooks, etc.

I call it "analysis paralysis."

~~~
tetraodonpuffer
I think it is paradoxically a lot harder now to start than it used to be, way
back you had basic on your computer (if you started when I did) or maybe turbo
pascal (some years later), and that was it, you wanted something you started
to write.

Now say you want to put together a web application, you're going to google and
immediately you'll get a billion stack options with very opinionated people in
each camp, it's hard to choose what to do.

Having _some_ guidance to start is good, otherwise you end up like I did in my
teens, where the second program I started writing was a text adventure game
where every room was a separate block of code with if/equals text parsing
where I eventually ran out of memory due (64k wasn't much) if I had found that
article talking about text parsers and data structures it would have saved me
a lot of time :)

Nowadays though it's hard to get only _some_ guidance if you want to start on
something, and so analysis-paralysis is a significant risk.

~~~
vectorjohn
I've been a full time developer for 8 or so years now, and I can say, the most
complex personal projects I ever finished were when I started in BASIC, before
I knew what an array was.

That is partly due to lack of motivation to work outside of work, but partly
due to analysis paralysis when I try starting a new project. I get pretty far
in, and then realize all the things I should consider and scaffolding I need
to build, etc, that I lose interest.

So in other words, I agree.

~~~
seivan
Yep. The more you learn, the more you realised how little you knew. It's
pretty bad actually. Not sure how to get out of it.

~~~
TeMPOraL
There's a trap hidden there as well, one I realized only recently - you not
just realize how little you know, you are also increasingly unable to discern
the importance of it.

Say you want to make a homepage. You've learned of Node.js, you've discovered
Chef and Ansible, you've heard of Docker and Redis, you've seen Heroku and
DigitalOcean. Where should you put it? Which tool should you use for
automation? Is Grunt enough, or do you need Gulp? Which Yeoman generator
should you use? Is LESS better than Sass?

The answer it: _it doesn 't matter, ignore that stuff_. Grab a random hosting
(or VPS, if you know your way around Linux), hand-write some HTML and CSS,
sprinkle with JS and that's it. You don't need IT infrastructure management,
you don't need build tools, you don't need _any_ stack. Just make that
homepage, maintain it for a while, and notice which parts are the most
annoying. Then think about how you could make those pain points disappear.
_Then_ see if any of those cool tools can help. It's much easier to understand
them if you know what problem they're actually solving.

~~~
x0
Honestly I love this comment. That is _such_ a good way to look at things.

And here I am today. Ostensibly trying to remake my website, but actually
dicking around with about 4 different PHP frameworks, switching back and forth
every few hours. I think I'm going to go grab the HTML/CSS from it, and go
back to basics.

------
LukeB_UK
I don't learn through reading a book, I can't apply it to a scenario in my
mind. I've tried.

I do learn through playing around with code and deconstructing existing code.
There's a crucial second step to this bit though - working out why it works.
Without that, you've not really learned anything at all, you just know that if
you poke it for a bit, it will eventually work.

People can get negative effects from tutorials, documentation, stack overflow
too. Mainly where they see a piece of code that works, copy-paste it, tweak it
a little and then leave it there.

I think the article is based around the wrong argument. The most important
thing is working out how it works, not how you get to the stage of having
code.

Edit: Not running code before committing and seeing that it works sounds
horrible, is this a done thing? I feel it really shouldn't be.

~~~
agumonkey
Sometimes reading does give you an epiphany. Even though most for me too of
the time a from scratch bit by bit building is the best way to learn.

~~~
LukeB_UK
I still read stuff, but it's usually when I'm in the "how" stage and focused
on what I've written rather than just generally reading.

------
dkarapetyan
I think it's a shame that so few people these days know what a smalltalk
development environment looks and feels like. There is no distinction between
learning and experimenting. It's all part of the same feedback loop. It's a
shame that almost no modern programming language these days provides the same
kind of workflow. If they did I think the author would have a different take
on learning and experimenting all in one go instead of segmenting things the
way he did.

~~~
Kluny
Feel free to write an article and tell us about it, I'm interested.

~~~
dkarapetyan
It's just a vague recollection now. I wouldn't be able to do it justice. It's
one of those things that doesn't translate well into words anyway. The best
thing you can do is download Pharo Smalltalk and start playing:
[http://pharo.org/](http://pharo.org/).

------
enobrev
I agree with a lot of the posts here, but noticed one way of learning
(specifically about programming, but it applies to most creative endeavors
I've enjoyed) that I have not seen mentioned, which is to learn by teaching.
I'm self-taught, and there is an enormous segment of things I've learned by
trying to help someone with something I had No Idea how to do.

A couple lifetimes ago (say, 99-01) I used to spend a lot of time on a back-
then-well-regarded designers forum, and every time a web development question
would pop up, I generally didn't know the answer. I was just learning, myself,
and the questions always intrigued me. So I'd dig in and start googling and
hacking and reading / researching and documenting and finally write up a
thorough response. Follow-up questions came with more hacking and research,
but always ended in an answer, even if it was "no clue - but here's where I
ended up...".

I'd eventually become very well known in that community as an experienced
developer, though I was generally answering questions I had no business
answering. That turned out to be very lucrative for me over time as those
designers got further into their careers - some of whom I've been working with
on-and-off for more than a decade.

I did the same in the early days of StackOverflow. I'd see an interesting
question pop up that I knew absolutely nothing about. I'd open up my IDE of
choice at the time and start hacking away. 50 browser tabs and a few
iterations later, and I'd have an answer. Sometimes it was weirdly brilliant.
Sometimes it was ridiculous. But I'd learned TONS along the way.

I still do the same when I start new projects. I start with my own questions.
I flip everything I've done before upon its forehead, ignoring previous
assumptions. I open hundreds of tabs and email myself a whole bunch of links
to read after I've slept a bit more. And then I pick a few things that seem
reasonable and start running until the project looks like something tangible.
I've built quite a few successful things this way, and consistently learn
quite a bit more every step of the way.

------
chrishare
I don't disagree that it's important to really understand the code/system/tech
that you work with and change, but I personally only reach that understanding
in the first place through trial and error. My preferred way of learning is
always to do a little reading to build a mental model of how something works,
and then a lot of experimentation to validate or invalidate that model.

------
proksoup
"Just trying things in production" is a serious problem.

"Trying things in development" is I think a necessary step in learning ... you
have to get to that point eventually, and that comes I think before the
"change" thing the author is worried about. I am concerned that the author's
concern the way it is worded in that article may inhibit this desirable step
in the learning process.

"Just trying things in development, if it works, push it down the line,
instead of digging deeper" seems the problematic thing to me.

------
a-dub
I have no idea what I'm doing but I'm writing about what makes a good
programmer.

------
petke
And then there are people who like reading and learning about coding more than
actually coding. We don't get stuff done because it isn't perfect.

~~~
Strom
Oh yes, I battle with this all the time. Then once you finally finish coding
some part, you'll have learned a lot once again, so instead of working on
another part, you feel the need to refactor/rewrite the first part instead to
get it closer to perfection.

~~~
TeMPOraL
In my case it was a phase. In time it switched into "oh shit oh shit I
couldn't code my way out of a paper bag if my life depended on it", and then
it stabilized.

------
chris_wot
He's got a reasonable argument - to a point. I've done massive quantities of
reading myself. But hacking away at the LibreOffice codebase has taught me
that for everything I know in theory, I'm not necessarily able to implement
straight away in practice.

I've had occassions where I've had to try to work around issues, but it
_really_ helps to have experienced and helpful devs around on the Freenode IRC
channel. I mean, they expect you to do your own research first, but if you
really are stuck and need some pointers they are pretty helpful to have
around. And they help you progress with your coding.

So I think theory is great, but mentorship (even informal and sporadic,
because getting advise from experienced devs is, IMO, a form of mentorship) is
pretty much essential. Not all theoretical ideas are going to work well. For
example: design patterns. These are great and I'm a massive fan, but they
won't necessarily be useful in all cases. Let's say you decide to implement
the Composite Pattern - well, not a bad thing. But if there is a performance
critical part of the code then it may not be the best thing to use.

Another issue, of course, is where there are differences in opinion on how to
do something. Some people really want to use relational databases, others
graph databases. If you read up on the theory behind a graph database, but not
on relational databases, then you might decide to use them where they aren't
appropriate.

And then there is the issue of the sheer scope of reading about a subject.
Often there is so much information that you can get lost. Or it's so advanced
that it's hard to get started - though in most areas I'm finding that this is
getting much better as information is disseminated more widely on the Web.

------
baudehlo
I'm very thankful for people like this who acknowledge they don't know what
they are doing. I've worked with far too many people who are convinced they
know exactly what they are doing (and argue with you ad-infinitum) and truly
haven't got a clue. It's painful.

~~~
tyingq
The article isn't quite what the title implies. The author does, in fact, seem
to be convinced he knows exactly what he's doing, all the time :)

------
quanticle
>Good developers know how things work.

>Great developers know why things work.

I disagree. I don't think anyone who knows the how but not the why ought to be
calling themselves a developer at all. Knowing why an application is laid out
the way it is a key prerequisite for knowing what parts of the application you
can change easily, and which parts will require careful regression testing.

~~~
derefr
That assumes that knowledge is available from some extra-textual source (e.g.
other developers.) I think the author means to say that great developers will,
_when handed an arbitrary undocumented mess_ , seek to use the code build a
mental model of the _intent of its designer_ —whereas regular developers will
stop after building a mental model of the code itself.

~~~
chris_wot
It depends. There are cases where the intent of the designer is bat-shit
insane and it's just not worthwhile (after a while) to really get to grips
with the code. There are times when it's best to rip out the code and replace
it entirely.

Admittedly, this occurs less frequently than when refactoring would be
appropriate, but it does occur.

------
Walkman
The author is right. I met these kind of "programmers". When I started working
at my current company, I was promised that I can learn from senior Python
developers with 5-10 years of experience. I had 2 years of experience at that
time. They couldn't teach me a single thing about Python in 10 months. They
write code without any basic knowledge what is happening. They don't even know
the tools the other developers wrote.

Example 1: Guy (10 years experience) is running an svn admin command on the
main production repository he never tried before, (never read the manual for
it) realize it doesn't do what he thought it would do, and press CTRL-C
wildly.

Example 2: I set up Jenkins for automating deployment, installed a couple of
plugins for it. Guy (5 years experience) made a deployment job using a plugin
without reading (or asking me) anything about it FOR THE PRODUCTION
ENVIRONMENT. Took hours to find out he thought the field does one thing but
it's purpose nowhere near. A couple of minutes reading upfront would have
spared 3-4 hours of unnecessary work and frustration for him.

Example 3: Guy (10 years experience) wants to write an XML parser which deals
with unicode. Randomly(!) putting encode() and decode() calls and cursing that
accented characters doesn't appear correctly. I explained to him how he should
approached the problem and he succeeded at the and. I'm not sure he could have
made the program work correctly or if he did, he was not able to know WHY.

Example 4: Guy (10 years experience) comes to me asking help about locale
switching in Python. I never used that part of the standard library, so I just
opened up the Python documentation and worked out the solution in 5-10 minutes
(he sitting next to me). He did not even looked up the documentation for the
function he was calling. I'm pretty sure he wasted more than 10 minutes trying
to solve the problem...

I had an "AHA" moment when I realized if I read upfront much more
(documentation, manual, any kind of help page) about the topic I'm about to
use, I can finish much-much faster and understand the problem from the first
moment much more deeply.

I started learning Python by reading the whole tutorial [0] upfront and
learning Django by reading everything in the documentation, like I was
learning for an exam. In two years I gained much more knowledge about Python
than any of these guys.

[0]:
[https://docs.python.org/2/tutorial/](https://docs.python.org/2/tutorial/)

~~~
collyw
Thats an interesting approach to learning. I have used Django for nearly 5
years, more or less full time, and I haven't read every part of the
documentation.

I did read through all of the stuff about mixins for generic views, and at the
time it didn't make much sense.

A while later I started using some formsets and the django-extra-views
package, and using class based views for a small project. After that hands on
work, I see how they all fit together.

~~~
Walkman
The best for me to read upfront a bit and understand the big picture well,
then dig into, do something with it. If I don't understand parts, I read it
again and code it again. I rewrite things all the time :) as I learn new
concepts.

------
m3gatr0n123
I have a different opinion on this. There are 2 types of programners: 1\. The
novice - I have no idea what I'm doing 2\. The experienced one - I am A god
It's as simple as that!

