1. There is no substitute for the hours spent coding. Sure, you can waste a lot of time, but there's a high correlation between hours spent and skill attained.
2. You can do almost anything with almost any tool. The energy spent debating tools would probably be better spent building something.
3. One of the biggest differentiators between a good coder and a poser is the willingness and ability to go several levels down. Deep understanding comes from deep diving.
4. One of the best ways to deep dive is to benchmark. The milliseconds gained will be a byproduct. The real benefit is your understanding of what goes on under the hood.
5. Write a framework. You may never use it, but you'll never be the same programmer either.
6. Almost everything you do will take longer than you expect, no matter how experienced you get or how good you get at estimating. If it doesn't, then you're not taking on challenging enough work.
7. Once you regularly deliver great value to others, you will often feel like an imposter. The compliments will exceed what you think you deserve based upon how hard it was for you to build. That's OK. Accept it and enjoy it. It's payback for all those hours you slaved away and no one knew what you were doing.
8. If you maintain a sense of wonder and delight every time you get something new working, you will probably never get burnt out. Don't let anyone tell you otherwise.
9. When you look at your old code, most of it will suck. That means you're always getting better. But some of it will still amaze you. Embrace and harness that energy. Try to recreate the conditions under which you wrote it.
10. Name your variables properly. That will always be half the battle.
> 1. There is no substitute for the hours spent coding. Sure, you can waste a lot of time, but there's a high correlation between hours spent and skill attained.
Even the time wasted is valuable, and not just for racking up hours. Wasted time includes making mistakes, and once you've made a mistake then you've seen that mistake. This means that when you later see the results of that mistake, made by you or a colleague, you can quickly consider if it's that same mistake; often it is.
We've all asked someone for help about something weird, and that someone gives us an immediate suggestion. Chances are it's because they've made and seen that mistake in the past.
> 7. Once you regularly deliver great value to others, you will often feel like an imposter. The compliments will exceed what you think you deserve based upon how hard it was for you to build. That's OK. Accept it and enjoy it. It's payback for all those hours you slaved away and no one knew what you were doing.
That's a byproduct of learning any craft. It is not the act of writing 20 lines of a script in 10 minutes to process that file that makes you amazing. It is the fact that you know what 20 lines to write.
11. Learn to read, navigate and understand code! Unless you are working alone (but even then) you will spend a lot of time "uploading" code to your brain. Code is read more than written.
12. Algorithms are not nearly as important as some people make it look like. I can't really remember if I ever wrote a sorting routine that is used in production and I am still waiting for the moment A* will be useful. And when that moment comes, I will just need to _read_ it on wikipedia.
Re 12: It happens (sometimes? eventually?). It took me 15 years though until that point came. And the answer was just looking at Wikipedia and other code samples in other languages to get some understanding of it. I also implemented it wrong and it kind of worked (not as well, but well enough) and only realized my mistake months later.
Why the downvotes? Algorithms are interesting and every programmers benefit from studying a few, but very many of them already exist in permissively licensed libraries.
Re: #7, there's sort of a catch-22 with that, and not just with software, with any creative endeavor.
If you struggle, bash your head against the problem, put in a lot of hours, and eventually produce something that works you may feel like you don't really understand what you're doing, that you only managed to produce something by brute force and luck (which may sometimes actually be true).
On the other hand, if you breeze through something and knock out a solution with little effort it may seem like you're not actually doing anything at all.
It's easy to undervalue knowledge and the difficulty of acquiring it. Just as it's easy to undervalue merely putting in the time and effort even when skills are underdeveloped. What ultimately matters is whether or not you were able to build something worthwhile that wouldn't have existed without your effort.
Re: #10, also use good commit messages. I find this harder with smaller commit increments such as with using git. Lately I've tried to avoid using "change" or "fix" as the first words in my commit messages.
I find that it goes away with experience. Over time we learn that the true value in our output isn't to ourselves, it's to the users.
I see users of a simple file parsing utility that took me an hour to write gushing over the amount of time it saves them every day and it just makes me feel good to be able to help someone with such little effort.
Not everyone is the same, for some it doesn't go away as easily. I've heard plenty of stories from talented artists, makers, and devs of falling into that mentality. It can be difficult to kick for the reasons I laid out. When it's hard it feels like you're a fraud, when it's easy it feels like you're cheating. It's not true, but people should be aware that these sorts of feelings are pretty common.
I'm reminded of the scene in Office Space where people are brought in an asked to describe what they do. That sort of thing is harder than one may think, it can be difficult to fully sum up how one works and in what ways one's skillset and expertise is valuable. For several years I had a job that was very difficult for me to describe to others succinctly. Mostly because it was hard to explain what I did if you didn't know many other details of the development process within the organization, some of them highly technical.
To use an analogy, it's a bit like asking why Beethoven is good music (without falling back on popularity). To express such things succinctly can be quite difficult, more so if you're put on the spot. Most people don't spend hours and hours thinking about how to justify the value of their own work, because that sort of thing can seem egotistical, more so if they already suffer from imposter syndrome. And without doing that when they put themselves on the spot they'll fall into the same trap of not having a good answer.
Number 5 is right where I'm at right now. I'm still really new and have spent my time learning Ruby and Ruby on Rails. I've recently embarked down the Erlang path. The frameworks aren't nearly as developed as Rails and I've realized I have no idea what the hell REALLY happens on the server side. My current goal is to write a server and my own framework. I have no illusion that either will ever be used for production. But I know I'll never get to where I want to be as a programmer if I don't understand what's going on back there.
By the way, nice to see a post from you. It seems like it's been awhile.
I'm a little bit further on that point and I think you should slow down a bit.
(All that follows is my humble opinion, apply grain of salt and critique as needed)
Writing a framework for the first time is hard. You said you don't really know what happens server-side and this may get in your way. A framework is often designed to address specific problems/needs in a specific context.
These problems/needs don't have to be shared by anyone else, it could just be you thinking "It's hard to build RESTful urls, I should build something to do it for me" and have a CLI util or a script handler that would register them for you in your app server. And some can be everyday problems: "F*ckin' databases, how do they work?"[1].
However, you need to know these problems to address them. Which is a part of my long-term feud with frameworks: "If you always use a framework, you will never have (too much) problems and will never learn how to solve them" (writing my own active-record-like ORM for node.js is a lot of fun actually).
Which is why my advice to you is: Don't write a framework.
Instead, write an app, get stuck a lot of times and find a way. Identify your problems. Then write a different app. This time, look at what you are doing the same way, what problems you are solving another way and what you'd like your framework to automate. There, for this second app, you can start writing your framework because you'll have a better idea of what you need to address.
You don't really need to make a framework that caters to everyone's needs, but one that caters to your needs and expand from there.
Next (optional) step is rewriting the first app with the second app's framework and iterate new functionalities.
I solved this problem by using Sinatra rather than Rails. For most things you will build as a novice coder, Sinatra will do what you need and get out of your way.
When you start building bigger stuff, and your routes and controllers start looking crufty and ugly, and you start wishing you had more tools to keep everything organized, then pick up Rails.
I suppose you could try to hack together your own framework to give you a sense of what's involved. In Ruby this is done with Rack, it handles the HTTP requests and you can focus on the mid-level framework-y stuff. But seriously, Sinatra's what you'd eventually come up with, and it's already out there, so why not use it?
Excellent list. I would add to #3 to read the source. Many frameworks are open source so they are easy to link in the editor and follow all the way down. Even though something like iOS isn't open source, the headers are all available and have tons of information.
#8 is why I've been coding for years. There is always something new and interesting to do.
1. There is no substitute for the hours spent coding. Sure, you can waste a lot of time, but there's a high correlation between hours spent and skill attained.
2. You can do almost anything with almost any tool. The energy spent debating tools would probably be better spent building something.
3. One of the biggest differentiators between a good coder and a poser is the willingness and ability to go several levels down. Deep understanding comes from deep diving.
4. One of the best ways to deep dive is to benchmark. The milliseconds gained will be a byproduct. The real benefit is your understanding of what goes on under the hood.
5. Write a framework. You may never use it, but you'll never be the same programmer either.
6. Almost everything you do will take longer than you expect, no matter how experienced you get or how good you get at estimating. If it doesn't, then you're not taking on challenging enough work.
7. Once you regularly deliver great value to others, you will often feel like an imposter. The compliments will exceed what you think you deserve based upon how hard it was for you to build. That's OK. Accept it and enjoy it. It's payback for all those hours you slaved away and no one knew what you were doing.
8. If you maintain a sense of wonder and delight every time you get something new working, you will probably never get burnt out. Don't let anyone tell you otherwise.
9. When you look at your old code, most of it will suck. That means you're always getting better. But some of it will still amaze you. Embrace and harness that energy. Try to recreate the conditions under which you wrote it.
10. Name your variables properly. That will always be half the battle.