How do I retroactively learn knowledge I should have picked up somewhere along the line?

Question

My job title is senior developer, but I've somehow always ended up working for companies that don't really take best practices too seriously, and I've let myself fall into the mind set of getting the job done as fast as possible, and not always in the best way possible. So I now have a large collection of bad habits that I want to get rid of and replace with a large collection of good habits.

So where is a good place to get started on listing bad examples and how they should have been done better.

As an example: I always end up with meshed together data and presentation layers: This should be done with (I guess) a multi-tier design, but whenever I get started on one of these I end up trapping myself more than making my life easier.

So what I am asking for is a if anyone has any good ideas/articles on how to get the wayward developer back on track and more productive than he was before.

Answer 1

• Read Code Complete
• Read The Pragmatic Programmer
• Try to make some good changes around your job, that reflect good practices

Answer 2

I would read Code Complete. It has a lot of good stuff like that in it.

Answer 3

My suggestion is to read "Domain-Driven Design" by Eric Evans.

It has excellent examples of using layers, and how and why to use them.

Answer 4

Have a look at "The Pragmatic Programmer" ...

Answer 5

Read Joel On Software. His stuff is very well written and entertaining in addition to being extremely useful.

Answer 6

Pick a project, whether a personal or a work one and say,"I am doing this with Best Practice in mind." Start on a small project so you have a better chance of sticking to your goals and work from there.

As corny as it sounds; "The desire to put forth effort is directly proportional to the outcome." As you start to incorporate these better practices over and over they will become habits.

I assume that since you are able to recognize your bad habits that you have a decent idea as to there opposite but the mentioned books are a good start if not.

God Speed!

~P

Answer 7

All the reading is great. However You will not really learn until you implement the practices in the great books that have been mentioned.

Answer 8

I would also recommend forcing yourself to do things on some personal projects at home. For example, create a simple crud application against the Northwind database. Start by Adding the Windows Forms application and then immediately create 2 additional projects, one for the DataTier and another for the Business tier. Force yourself to use them with the knowledge that after you finish you will immediately change the presentaion to use ASP.NET and reuse existing code.

I would also recommend looking at some of the free open source projects that are pretty large and see how they did things. You can't create a large open source project that will be successful without making some good choices on best practices.

Edit: I should also say, good for you for being upfront about this. I know from experience that it can be something difficult to own up to so congratulations for not letting that be a stopping block for you to learn how to do things better.

Answer 9

If you have a long commute or other times where you can listen to podcasts you may want to listen to Software Engineering Radio It won't teach you how to write the code or the ins and outs of librarys but it's a good introduction to a lot of concepts.

Answer 10

I've had the same issue, as I've worked in lots of places where the standards, were .... (cough, cough) ... challenged.

Reading about "best practices" isn't necessarily the best thing, as there's an awful lot of hype on that subject. (some good discussions on this - controversial programming opinions, best practices considered harmful) Best things I've found:

As others have noted, any kind of Supplementary study, e.g. Learn a new langauge, study basic algorithms (it's the kind of thing that can get lost in the shuffle as you can often ignore it during the normal day-to-day). Really, any subject you're interested in.

The biggest shift for me in my supplementary study is more like a shift in habit. I used to read through a lot of information and "sort of" get it (started to notice this when I found I couldn't answer questions on things I thought I knew). It's much, much better to stop when you don't quite understand something and research it till you feel like you really own it, and so to really learn something, even if it's only occasionally, than to take in a lot of information but not really digest it. I've found this site to be great for that, as invariably someone will mention something I'm not familiar with.

Answer 11

For me I find a lot of it is just allowing yourself to do it the right way.

I've worked with people who ALWAYS cut corners, and it wasn't that they wanted to, they felt that was what they were supposed to do, that they would be failing their company if they didn't write the quickest code they possibly could. Once I gave them the excuse to just do it the right way, they started coding differently almost immediately.

Do you really need evidence that cutting corners doesn't save you any time? If you look at how much time you spend gluing the corners back on when everything goes to hell in QA, you must understand that there is no savings at all--even in the short run--even for prototype code.

Since I figure you spend about the same amount of time regardless of weather you're creating good code or bad, I figure I'd rather err on the side of good.

Write yourself tools, spend time refactoring, insist on DRY code! Keep finding ways to DRY out your code.

Always revisit your code 3 or 4 times. Go back and re-read it the next day and see if everything is completely obvious at first glance. If you have to think for 2 seconds, you're doing it wrong! It will be completely incomprehensible in six months.

Don't allow anything to look complex, make everything plain and obvious.

Remember, the primary goal of the code is not to make your computer do something, it's to make the next human reading it able to understand and modify it.

Just keep at it. Keep improving your skills, keep refining your code. Look for techniques that give you better refactors.

Just make the decision, everything else follows easily.