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.
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.
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.
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.
Experience does not equate to cynicism, or at least shouldn't in a 'good' developer. And experience is indeed a common 'replacement' for youthful enthusiasm, mostly because greater experience (usually) brings with it lower risk, faster / cheaper development and a greater chance of success of the project. If you are a junior, no matter your level of enthusiasm, you often don't know what you don't know.
Personally I'm happy to work with people of all 'types' as it's possible to take the best from them and ignore the worst (unless it's destructive to team spirit and the success of the project). Many occupations have their cynics and difficult or annoying personalities, software development is no different.
I went through phases. At first I'd go on an on about having the most awesome process out of all the companies so as to make programming awesome software into an assembly line, then declare any programs written in Java or C/C++ to unmanageable untelligble dreck, to declaring assembly the best language because it gave you the most control.
These days I'm in a phase where I am curious about improving the development process in simple (but high impact) ways that do not interfere much but nonetheless are hard to voice because of their social unacceptability, like not comparing developers quantitatively and changing the culture from "works on my machine, push!" to "test your damn shit!"
It's interesting that this thread is so much more important than what the author was originally talking about. I hope he gets a chance to see it. A lot of us seem to follow the same path. We complain about the same things at the same time in our careers. We see our way around it only to meet another stumbling point -- that everyone else on the path has also hit. It is probably the most interesting (and annoying!) thing about my job ;-)
It doesn't take much experience to point out what others are doing wrong and say what they should be doing. However, it's much harder to pick these things out about yourself and do things right yourself. It's always easier when you're on the outside looking in.
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.
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!
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 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.
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.
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.
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.
I like your answer but it genuinely wouldn't work. Suspect, most of us know those things already.
I don't think you can tell someone who suffers from analysis paralysis that it's irrelevant.
You can tell them, but it might not matter. I 've come to the conclusion that the only thing works is an "authority". School, parents, work, boss, client. Basically anything that directly controls your life.
Not to diminish anyones experiences, but indecision from analysing things it's like a drug, at least for me. I feed off it, and suck and impacts my life, but not instantly. Over time.
I can't pick a project to finish because I only have 4 days, but then 4 days pass, and you still haven't. Now increase that into a weeks or months.
If you know about the dunning Kruger effect and then apply knowledge of imposter syndrome you can power a small turbine with your self-image as it flips back and forth.
Sure guidance is great. As much as I was a 14 year old know it all pain in the ass, my old highschool CS teacher taught me the most important lessons of development: memorable variable names, syntax formatting, and saving frequently.
However, there were at least a thousand programs I'd written before and after that involved huge if/else and case statements because I didn't know better or couldn't anticipate growth. Copy/paste code littered throughout.
All of that 'bad' code was there because I wasn't worrying about making my code good (and barely knew what good code should look like), I was trying to make it work and solve a problem. That bad code made all of us who we are today- someone who starts their coding journey out only trying to write good code will never get finished, and probably give up.
Hell, I'm 33 and have been writing code since I was 9 and am considered a 'rockstar' developer and architect by my peers (which is probably more of an indictment of their judgement) and I often still disregard the ugly for the path to the solution, then go back and refactor/cleanup/make portable after I have large blocks of code written. The only difference now is that my ugly is a WHOLE LOT prettier than my best used to be.
Both of these examples I feel are like the difference between learning as something that increases a person's capacity to do something, and learning as a "sport," to just kind of get some notches on the keyboard.
This is slightly painful reading. As someone on the periphery of coding I've been stuck in that loop for years that are rapidly approaching a decade.
I think more than just doing these things it's vitally important to have people around you that you can ask questions to. While I'm sure there are some autodidacts who can make do with an IRC channel and google I've only ever had things stick when there's a real life person in the room I can keep on asking dumb questions to.
The problem with 'just coding something' is your stuck with tiny problems and lessons related to those tiny problems. IMO, once you get past the basic, I can program tick tack toe by hand, you need to take a year or two and learn from other peoples mistakes. Otherwise, most self taut programmers have a world of bad habits that only really bite them when part of a team.
The only real exception to that is when you have someone on hand to read your code and offer real advice. Don't use a for loop here use a foreach. Functions should mean something, don't just cut a program up and stick the top half in one function and the bottom half in another. etc etc.
PS: Number one thing to look for in a first job is a company that does real code reviews by competent people.
My suggestion is that people who are learning, especially if self-taught, should dive into other peoples source code as soon as possible. Build something of medium complexity, then choose a couple of either the simplest or most useful libraries you used, and start reading the source.
Moreover, being aware of the pain points lets you actually understand what various popular tools are about. You can then start incorporating them into your projects because you know what problems they're solving. It's easier to understand the value of, say, Docker if you had to develop your project on three different machines and went through setting up the environment and dependencies on each of them.
I completely disagree with your summarization. The emphasis is on understanding both the problem domain and, more importantly, the codebase. Understanding the problem domain may come from reading books, but it may come from asking senior members of your team, too. Understanding the code base will not come from an appreciation of the theoretical, however. Modifying code whose interactions you don't have a solid understand of is a recipe for disaster, but occurs all too often.
> The primary emphasis of this article seems to be: "Stop playing with code and start reading books".
It's more like "Start reading books about the code you play with".
Personally, I've always hated when people copy-paste some code without bothering to understand it and I think this is also what the author rants about.
By "bothering to understand" I mean read the code author's comments or docs, then read the code and make sure it looks like it actually does what's advertised, modify things you don't like/need, play a bit with things you totally can't understand. Test it before plugging into something bigger and having to debug it then.
Or, to use OP,s analogy: Got an appliance? RTFM before you waste few hours using it suboptimally or it cuts your fingers.
Programming any nontrivial piece of software not covered in a tutorial is not going to be in a book. Or it should be?
But there are cooking recipes where as long as you have the tools and ingredients, you can follow the steps and learn/generalize from that and you're cookin'. Same for just about any non-joke topic on wikihow.
Call me when there's a book on exactly (I mean not just talking in useless generalities) how to build and maintain a particular modern machine learning / robotics control / operating system.
There just isn't, because a) they are that complex and b) our culture discourages actual education when it comes to programming. Hell, even auto mechanics, maintenance programmers of the physical realm, get Haynes manuals for all the vehicles they might plausibly work on, which is a goldmine of material for knowledge development.
Right now, it's just so much more efficient to actually run the damn code and let the computer collect your data. I feel like software engineers of the future should write down everything they know about the programs they are working on, or at least all the steps of development and maintenance, so it's easier to get their internal theory.
Playing with code is a great way to learn things! I mean, yeah, don't check in your experiments, but the notion that you're going to gain more from reading a book compared to actual usage... I don't know, it probably depends on the person, but either way is a totally viable way to learn things.
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.
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.
Fifteen years ago, we had people who felt the same way about Smalltalk, so they wrote a major enterprise system around it. Many other groups in our organization came to rely on these central services, so strange things were done to make it scale.
Smalltalk was supposed to be a teaching language - pick an enterprise stack when you want to build something serious, but go ahead an learn on Smalltalk, Forth, Lisp, etc. Understanding other programming languages (especially when they're using different "types" - functional, declarative, imperative) will make you a better programmer.
> 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.
A little surprising given that the author seems to have experience with Clojure. Lisps have a line between learning and experimenting quite blurred as well, though Clojure is probably not as far into this as Common Lisp or Scheme.
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/.
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.
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.
"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.
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.
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.
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.
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.
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.
> I disagree. I don't think anyone who knows the how but not the why ought to be calling themselves a developer at all.
So, you have never worked with insufficiently documented closed-source technology, where the only way to achieve required result or, especially, optimize performance is trial and error?
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.
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.
That would be about my reading of this article as well, at least my most charitable reading. Peter Naur's "Programming as Theory Building", while not getting some important points right, is right enough to set anyone on the right track.
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.
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.
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.
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!
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.