Learning to be a good developer: what parts can you skip over? [closed]

Question

I have set myself the goal of becoming a decent developer by this time next year. By this I mean full experience of the development 'lifecycle,' a few good apps/sites/webapps under my belt, and most importantly being able to work at a steady pace without getting sidelined for hours by some should-know-this-already technique.

I'm not starting from scratch. I've written a lot of html/css, SQL, javascript, python and VB.net, and studied other languages like C and Java. I know about things like OOP, design patterns, TDD, complexity, computational linguistics, pointers/references, functional programming, and other academic/theoretical matters. It's just I can't say I've really done these things yet.

So I want to get up to speed, and I want to know what things I can leave till a later date. For instance, studying algorithms and the maths behind them is interesting and all, but so far I've hardly needed to write anything but the most basic nested loops. Investigating Assembly to have a clearer picture of low-level operations would be cool... but I imagine rarely infringes on daily work. On the other hand, looking at a functional programming language might help me write programs that are more comprehensible and less prone to hidden failures (at the moment I'm finding the biggest difficulty is when the complexity of the app exceeds my capacity to understand it - for instance passing data around was fine... until I had to start doing it with AJAX, which was a painful step up). I could spend time working through case studies of design patterns, but I'm not sure how many of them get used in 'real life.'

I'm a programmer with basic abilities - what skills should I focus on developing?

(also my Unix skills are very weak, and also knowledge of Windows configuration... not sure how much time I should spend on that)

Answer 1

These are suggestions based not on what I did, but what I think I should have done on hindsight:

1. Skip new hyped technologies because most of them will fail. Make exceptions for those you have a stake or a business plan, but always have an opt-out (replacement technology) strategy.
2. Skip becoming an expert on every programming language and library. Do try to become an expert on the relatively few (seven) programming languages and libraries that pay for what you like to do. That said, never miss an opportunity to try to understand the nuances of a different programming language. Becoming competent in a new language and its standard libraries takes about two months.
3. Skip single-platform technologies whenever there's a workaround.
4. Skip MS Windows. It has too many vices.
5. Skip becoming a specialist, but selectively allow others to think that's what you are.
6. Skip corporate voodoo ("user-driven, enterprise component architecture") if you can. It leads nowhere.
7. Skip C++ (let others deal with that) and wait for the Python bindings.

Actually, you can skip anything if you trust your ability to learn. I think that what you want to know would have been better served with a question like:

• I know this, and I'm lacking in that. What should I learn within a year from now?
• I like to have projects that pay well, but what I really like is such. What should I learn to get into that within a year?

Remember that good developers know about everything, because computing is rarely about computing itself, but more often about applying it to any field of human endeavor, be it theoretical physics, ecosystem preservation, or photographic effects in The Matrix.

Lastly, please do learn about design, abstraction, algorithms, and complexity. I, the programmers that taught me, and the programmers I respect will thank you and appreciate you for it. If you have time for study, I'd recommend reading the first edition of Code Complete.

Answer 2

Pick a pet application. This should be something that can start very simply but has some complexity as you dig deeper. It should also be something that interests you because you're going to be spending a lot of time with it. Also make sure it DOES something. Don't try to write a framework or a webservice right now. Just a regular user-driven app.

Download git, mercurial, or bazaar and learn how to create a repository with them (it's dead simple).

Now implement your pet project using whatever technology you like to the best of your abilities. Give yourself a deadline so that you can make sure it gets done. Use the source control repository you made to track changes. Don't worry about branches and the like, just make sure you are able to back out of mistakes.

Once you're finished writing your app, label it. That is your V1. Get Michael Feathers' Working Effectively With Legacy Code, Bob Martin's Agile Software Development Principles, Patterns, and Practices and Clean Code, and Andrew Hunt and David Thomas' The Pragmatic Programmer. Feel free to read them in any order, even to jump around between them. A lot of the ideas are repeated but they will also strengthen your understanding because they are presented from different perspectives. (You'll probably want to pick up the GoF Design Patterns book for reference)

As you read through the books, try to apply what you're learning to improve your project. Make sure you use your source control as a journal of sorts of the changes you make.

If done correctly you should have learned a number of good skills like: refactoring, test driven design, improving existing code, and how (and when) to apply design patterns (among other skills).

Ideally, you would have a mentor to help you gauge your progress. If interested, you can contact me (firstinitiallastname at kharasoft dot net), and I will help you with a plan and provide review.

Congratulations on taking the initiative to further your career! Many rewards will come from it.

Answer 3

You know the secret of a good developer?

You don't know it all but you know what you don't know and where to find more information on what you don't know when you need it.

• Knowing all what you mentioned in details is not possible - too much for a brain to handle.
• Remembering it all is not possible - the unused knowledge is erased from memory
• In most practical situations you don't need that much anyway

Trying to achieve impossible will only lead to anxiety, sleeplessness and the loss of self-confidence.

Answer 4

I think the answer is going to be different for each developer, depending on what he or she wants to specialize in. I recommend the following algorithm to determine a good answer for yourself:

1. Pick a simple project that uses a skill you are interested in learning.

2. Implement it, focusing on that skill.

3. Note what you do like about how that project turned out, and what you don't like.

4. For the things you like about how the project turned out, ask yourself, "Is this something I think I could specialize in that I would enjoy, or is it related to something I could specialize in and would enjoy?"
   a. If so, think of other skills that are related to this specialization and write them down.
   b. If not, pat yourself on the back, note it as something you are good at, and move on.

5. For the things you didn't like about how the project turned out, ask yourself, "Is this something I should know how to do (or want to know how to do), or is this an aspect of development I could and would like to leave to others generally?"
   a. If you think you want to or should know how to do it, add it to the list started in step 4a. b. If you think you could leave that aspect to others, sigh in a melancholy fashion over your limits as a human being, note it as a weakness, and move on.

6. Pick one skill from the list of things you could specialize in and things you should know from 4a and 5a. Choose whatever you think is most important to develop to get your programming closer to what you want it to be.

7. Brainstorm simple projects you could do that use that skill. Pick one, possibly a project that will let you practice another skill that is also high on the list so you can kill 2 birds with one stone (although n/2 is the same complexity as n, it will still be faster this way).

8. Return to step 2, using this project.

Repeat this loop for the rest of your life, or until you no longer desire to be a good programmer (hey, if you want to quit coding to feed hungry orphans, I won't stop you!).

I've been specializing in testing and n-tier web applications. My next project will be practicing TDD and maybe ASP .NET MVC 2. TDD is to further my strength in testing (I'm an SDET, so TDD would just give me insight into unit testing, which I don't generally do except for on my test tools) and to help with a weakness in good design as well (I hope), and MVC is to help with my weakness in front-end design. My list includes things like testing performance, web security, and working with a web designer to craft a good (and good-looking) website.

One other bit of advice that I received early on and have found very useful: Specializations can either be broad, or deep. In other words, dabbling in a little bit of everything is a kind of specialization. Keep that in mind when trying to work out what you want your specialization to be.

Sorry if you wanted something cut-and-dried. I don't think the question has such an answer.

Answer 5

I've been programming off an on for years (since I was 7 - I'm in my late 30's now).

If I were in your position the one thing I would strongly suggest - but which I don't see in most of the other answers is to find at least one other programmer to work TOGETHER with on a defined project.

As you do that read about Agile programming - SCRUM etc and work in an agile and test driven manner. Work together - but don't let one of your write most of the code - truly work on it as a pair of developers.

And while writing your own version of everything can be informative - the very best developers I know are masters at avoiding writing code EXCEPT for the stuff they absolutely have to do themselves - i.e. the core of what is unique about their project.

The rest of the time they will reuse code extensively - call API's, use open source projects (where appropriate) and in short avoid reinventing the wheel (or the data access layers etc) just for the sake of doing so.

And then in the course of doing this - especially with open source projects they will also contribute back to those projects - they will read the code, clean it up, fix bugs, contribute extensions etc.

Real world development is usually about working as part of a team - so I would strongly encourage you to do that. If you don't know other programers who want to work on a specific project with you I'd suggest looking over the 1000's of open source projects and picking one or more to become actively involved with - likely you can find one or more projects that scratch a personal "itch" - and very likely you will find a project you can contribute to and find other developers to work with on.

And personally I would discount the advice that your attitude of "skip what I can" is a bad one - when I'm hiring developers I want developers who don't try to do everything themselves. I'd strongly prefer developers whose first instinct isn't to write it themselves but developers whose first instinct is to see how they can achieve the business needs and requirements without writing code (and then via writing the minimal code needed).

All while also testing and keeping business requirements strongly in mind - and yes at times testing will show that you do, in fact, have to rewrite some code or write it yourself (at times you can then contribute this back to improve a project).

Answer 6

It's simply a matter of reading up and learn stuff when you need it.

If you get stuck somewhere or get a feeling that "my solution is missing something" -- that's when you should spend some time to learn more about it!

Answer 7

Trying to find bits to skip is not the best attitude to have.

That being said, you can aim to concentrate on certain areas once you get an idea of the which parts of being a dev you prefer.

Maybe stick to web development, to the detriment of windows dev for example.

I like to be a jack of all trades, as it makes me more useful.

Answer 8

In one year, you aren't likely to have "a few good apps/sites/webapps"completed, especially in a steep learning curve. The only thing you'll learn is burnout.

Instead, focus on one that you are interested in, and use that as your learning tool. Don't worry about it being production quality (it won't be), but use it as a sandbox that you can keep coming back to.

For instance, I'm interested in fantasy baseball. Over the years, I've developed many things related to that, from a screen-scraping stat gathering robot thing, to an HTML-only web site, to a full web app with a scalable SQL Server database feeding it, to.... My next pet project may be a real-time Silverlight app to allow the guys to sit around a virtual table to do the draft.

None of these things are all that useful outside of my world. However, each of them helped me become a better programmer, and to learn technologies outside my comfort zone.

Answer 9

Skip over the bit about worrying which language to start programming in.
Just choose one and go.
Spend your time learning the ins-and-outs of the API.

Here's why:

Which is better, XUL, Eclipse's SWT, or wxWindows? I don't know. They are all such huge worlds that I couldn't really evaluate them and tell. It's not enough to read the tutorials. You have to sweat and bleed with the thing for a year or two before you really know it's good enough or realize that no matter how hard you try you can't make your UI taste like real food.

Joel Spolsky, "Lord Palmerston on Programming" http://www.joelonsoftware.com/articles/LordPalmerston.html

Answer 10

I wouldn't worry too much about the "should-know-this-already" syndrome. In this line of work, you're always learning something new. Once or twice a year, my boss sends me a link to a 200-300 page document for a communications protocol or integrated circuit or something and he assigns me to become the resident expert on its contents. No one expects you to get to a point where you are "done" learning.

As far as the development process goes, just take that as it comes. You won't really know what's most useful until you do it wrong once or twice. Evaluate your performance and make improvements the next time around.

For example, last year I was having a lot of problems with build instability. I was scared to update from source control because it seemed like every other time I did, I would end up spending half a day getting everything to compile again. However, if I waited too long between updates, the merge at the end would be horrendous. I also occasionally have urgent bugs where I can't postpone updating, and which made it difficult to track partial changes I had already made for new features.

Well, my company is working on correcting that on a general scale, but I needed something I could use for myself in the meantime. I did some research on build stability, discovered distributed version control, experimented with some branching models, and now have a very workable hybrid system that uses several bazaar branches locally and my company's centralized source control when I need to share.

My point is if you had asked me two years ago what I should learn next about software tools and processes, I couldn't have told you. If you don't have a similar working environment to mine, a hybrid source control is just extra complexity for no marginal benefit, but it has helped my personal productivity and sanity tremendously.

Next up for me is working on my estimation skills, but I have no idea what will come after that, and I certainly don't know what some stranger on the Internet is going to find most useful a year from now. Only you can answer that.

Answer 11

I would like to share two points here:

1. Thinking in terms of algorithm would always help. When I was starting out I always use to think about real life scenarios and current algorithms behind them and always try to optimize them.
2. Never every quit Learning and Understanding New things/Technologies, in computers there is nothing like GURU, you always need to keep learning and you will have to accept this fact upfront and keep learning.

Answer 12

It doesn't matter what you do, as long as you stick with it and learn to do it well.

All of the ideas you've posted are good things to know and will help you. Which one interests you the most? You mentioned that your Unix skills are weak. Have you considered putting Linux on your computer? Knowing C already would help, as you could get your feet wet in programming Unix systems without having the added stress of learning a new language. That could also be an opportunity to learn about device drivers, if that interests you.

I would highly reccommend learning assembly and functional principles at some point in your developer education. Both have proved highly useful to me in my "normal" role as a Java programmer. I learned Lisp and Prolog. Personally I prefer Lisp, but that's a matter of opinion. Assembly teaches you to think about how the computer sees your program, and I think that that is important for every programmer to learn. functional programming teaches you to think more deterministically, which in my case has helped me to write more testable code and that is thread safe.

So, pick something that you like and spend a couple of months with it. You will be the better for it, and it may prove a stepping stone to the next project in your self-education. Oh yes, and whatever you do, do not stop learning. The second you do, you begin to stagnate.

Answer 13

Stop trying to learn to be a decent developer in a year. Learn to be a good developer in 10 years.

From the linked article:

The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music.

In a year you'll still be a gamble. There isn't anything you can do about that. Good companies look at juniors as an investment. What they look for isn't good current skill, but potential skill, a good grasp of the basics, and enthusiasm. You need to get these qualities across in an interview to get an entry level job.

How much programming do you do in your own time? That will probably the key factor to convincing a potential employer that you are going to improve fast. What projects have you completed? Completed projects show dedication.

I've only been employed at 2 different companies, but each had their own internal technology which I needed to learn before I could be productive. That initial bump won't reduce much with how much experience you have. Good employers expect an initial learning period.

Stop worrying and go program. :D

Answer 14

I'd just like to give you my steps of inspirational readings and my most turning moments so far.

There have been a few "WOW" moments in my software career. They went as follows:

Head First Design Patterns - This really opened up the world of OOP/OOD for me, an absolute staple.

Robert C. Martin - Clean Code - I didn't sleep for days with excitement from this! As simple as it is, boy had I forgot what it meant to have clean code, and this put me right back on track.

Robert C. Martin - Agile Patterns and Practices - I now live my coding career based around these principles. The word SOLID goes through my mind for each and every piece of code I write. This in combination with Clean Code, I was affected so much by them that, I convinced my employer at the time to let me teach it to the entire company of around 15 developers. I wasn't even a senior, good at presentations, but my enthusiasm made it happen.

My last "WOW" moment, was the discovery of TDD. I shared my realization of it with 2 other close friends who also had the same "WOW" effect. We were all hooked and now practice this as much as we can and always discuss the important of testing in the Software Development Life Cycle - better to have self verifying code than a team of much slower humans to do the testing for you ;).

One final point from me that I feel is very close to my heart, is that if you ever want a true fundamental understanding of a technology, such as a script parser, a REST library, a test framework etc, then write one! Just for fun! Not only will you enjoy it, but I've found that attempting to write the things I do not yet fully understand, gives me much more respect and a much much more deeper understanding of it, and forces me to understand it thoroughly.

Sorry, I just realized how much I may have digressed from the question. What I mentioned above has been my absolute core. None of the above material has left me, and gave me such great abstract thinking that learning has indeed become broader and easier. So, in answer to your question, try not to skip the core principles of code writing, and software design. Other specific tools for solving specific problems, aren't so important.

Answer 15

Learning and the accumulation of knowledge is like constructing a building, every brick sits upon another, they rely on their foundations.

If you start skipping things, rushing through, you end up with rickety facts, supported on air. You dare not use them for fear they will fall through, and they will. Facts can be false, if they are not partnered with reason, as you need to know their limits.

I am particularly concerned that you want to skip the foundations, mathematics, algorithms and their kin. Without a firm grasp here, you will never be able to do "anything but the most basic nested loops".

Do not be in a rush, work is there forever, time for uninterrupted learning is not. Learn all you can, in the order you find you need it, never leave a gap unplugged.

Answer 16

Like Jeff O suggests, if you want to be a good programmer you'll never quit learning.

You have to realise that there is so much you could potentially learn that is just related to programming that, if you wanted to know it all, and be good at it, you'd be there for millions of years. So just focus on what is going to make your life good. Whether that is pure enjoyment, money, scientific endeavour or whatever mixture of reasons, that's for you to choose and what you should invest your time and sleep in.

Ask yourself exactly what a decent developer is and do just that: practice your art on real life projects that will drive you to forget what time it is.

For me being a decent developer includes understanding how to obtain and write good requirements, how to project manage, how to test, how to present results, how to judge who might be able to help me out and who not (recruit), how to team-up with others, how to please the boss and the customer.

On a technical level, being a good developer to me includes being able to design, review, code, debug, test, write useful users' manuals, comment the code for fellow developers in a meaningful way, manage versions, simulate and always find a solution to improve productivity on a daily basis, to automate tasks (whether that's testing, debugging, data analysis for load forecasts or whatever). It means being able to do quick & dirty code when needed or warranted, but also being able to do clean, well thought through code.

All that is acquired not through learning for the sake of it, but learning for a purpose, to solve a need you have there and then. Learning for the sake of it is good to give you a solid base, but learning for a purpose is good for making it real.

A good developer in the end is the one who's able to pick up what's required for the task at hand.

Answer 17

It looks like you are all over the place. I think people learn most when they focus on a specific area and really dig in because when you do that you will invariably run into certain issues that will require learning some other tool. This way you can grow your skill set organically and in a highly interconnected manner so you won't lose the knowledge gained because each new idea or tool that gets incorporated into your mental toolbox will allow you to learn other ones much easier.

Answer 18

Pick a good Open source project that interests you and start learning it's code and contributing bug fixes and new features. That's something every programer should do.

Also, start a project right now, the only way to learn is trying to find solutions for a real problem. If you are not building anything then you don't have a problem to solve yet.