Developing computer applications is a difficult job, especially for the web. It’s a mix of science, art, and magic to make the machine function in the way you want, especially across multiple browsers and under tight deadlines. On top of everything, the technology is changing so fast it feels like a full time job just trying to keep on top of the latest developments.
One thing that is easy to forget amidst all of the attention that must be paid to specific technologies is that there is a lot of personal development that needs to continually happen in order to become and remain effective developers. Fortunately, there are quite a few smart people out there with significant experience who can analyze and communicate the lessons they have learned through their careers, and one of the computer industry’s most recommended sources is the book “The Pragmatic Programmer”.
This book is written by two men with a ton of experience developing applications, and they have written this book to share the lessons they have learned, and we can use these lessons to increase our effectiveness as developers. Also, despite the fact that this is focused primarily on developers, I think people in other areas can learn valuable lessons as well. There is far too much useful information in this book for me to cover all of it in a single entry, so I will probably cover more of it in future entries, so keep a look out. Also, there is a lot more detailed information in the book itself, so I highly recommend getting the book and reading it several times.
Two of the most important tips/thoughts when approaching our work are:
#1: Care About Your Craft
#2: Think! About Your Work
With every project we do, we need to care about doing it the best that we can. We should try to keep up with technology so we can use the best tools available to us, and we should make sure that we are cutting corners as little as possible (let’s be realistic, sometimes it can’t be avoided). Care about the small stuff even, because that will help you to care about the larger stuff.
Also, think about what you are doing, constantly, while you are actively doing it. Don’t wait until a code review to look things over, or until the end of the project, keep actively evaluating the decisions you are making and the work you are doing while you are working and see if there are ways you can make improvements. Try not to get stuck in auto-pilot.
Personal development of this sort is a continuous process…none of us will ever be the best that we can be, there is always room for improvement. Especially with a subject which is constantly changing, like web development. So, always be alert to becoming stagnant and thinking that you don’t have anything to learn…always be willing to try something new and evaluate the usefulness of technologies that you have been using for years. Perhaps there is something better out there, or just the act of learning something different will help you to use an older technology or process in a better and more effective way.
Section 1: The Cat Ate My Source Code
We work with many complex technologies, and generally under pretty tight deadlines, so no matter how careful we are, there are bound to be problems once in a while. The real question is, how do we handle them? We can either try to pass the buck and blame someone/something else, or we can accept that we made a mistake and make it right. Other times, we may be asked to do something that may not be possible, or at least not realistic for the budget. In both of these types of situations we should use the same sort of response, which leads us to the next tip:
#3: Provide Options, Don’t Make Lame Excuses
This is something that we talk about once in a while, but it’s always good to keep in mind. When an issue comes up, instead of placing blame or just saying something can’t be done, we need to think about what CAN be done. If there is an error, don’t make excuses, find a way to fix it. If a client asks for something you consider unreasonable, think about what you can do that is reasonable. Provide a solution. Before you speak up, stop and think about what you are going to say and filter out anything that isn’t providing a solution.
Section 2: Software Entropy
Entropy is a term for the amount of disorder in a system, and it definitely applies to software systems as much as it does to physical systems. Over time, projects start out nice and clean, and then under the pressure of meeting deadlines things start to get sloppy. Corners start to get cut, and mistakes become more likely. You may notice some ugliness but you just ignore it because you have to get something done…we’ve all been there. However, once you let one bit of mess into the system, even more will get added.
The authors tell a story about a study that was done in a large city where in some neighborhoods you could find one building in pristine shape and then right next to it would be a building covered in graffiti with all of the windows broken, in complete disrepair. The researchers found that what caused the much faster decline of some buildings was a single broken window. If a broken window was left unfixed, it invited people to do even more damage and rest of the building would go down hill very quickly.
#4: Don’t Live With Broken Windows
The same problems can happen with software. If you work on a project with some design flaws, poor coding, etc then it feels like it’s not as important to keep things clean and you may take more shortcuts which adds even more dirt. On the other hand, the opposite is true as well. If you start working on a project which is very well organized and has pristine code, you are going to work extra hard to not be the first one to mess it up. So, it is very important to keep things clean and fix any sort of ugliness as soon as it is found.
Section 3: Stone Soup and Boiled Frogs
There are a couple of good stories and some really useful information in this section, so I definitely recommend reading it, but I just want to go over a couple of what I thought were the most important points. The first one is:
#5 Be a Catalyst for Change
If you see something that could be improved, whether some business or development process, or something regarding development of a project, be a catalyst to make that change. If people are resistant, then there are some good strategies outline in the book that you can use, like starting the process yourself because people are more likely to join an ongoing success than get involved at the beginning.
#6: Remember the Big Picture
Another issue that can come up is that we get so focused on one little thing that we are working on that we lose sight of everything else around us. Lots of small problems can pile up and become a large mess because we simply weren’t aware.
Section 4: Good-Enough Software
When developing software, and especially websites in many respects, it can be difficult to determine how good a project needs to be. Of course we always want what we do to be as good as possible, but there are always trade-offs. Making our work “good enough” doesn’t mean low quality, sloppy code, or not putting effort into it, but instead has more to do with involving the client in decisions about how good things need to be.
#7: Make Quality a Requirements Issue
With the myriad web browsers available, we can’t support all of them, so we need to define what is good enough. Generally we do this in some form as a part of our scopes, we outline which browsers we support so we can focus on making the experience as good as possible for people using those browsers. Different clients have different requirements for what is good enough in this case. Similar issues pop up in terms of implementing client designs, does what we need to create have to match the PSD files pixel perfect, which might be more difficult to update in the future, or are they willing to trade some slight visual differences between the PSD files and the end product in order to have something managed by a CMS or more flexible for the future?
Section 5: Your Knowledge Portfolio
This is best summed up in a direct quote from the book:
“Your knowledge and experience are your most important professional assets. Unfortunately, they are expiring assets.”
This is especially true in web development, since there are constantly new technologies coming out and clients are always asking about some new trend. We have to keep aware of the technology in order to stay relevant. There are some key elements to build your portfolio, which are covered in more detail in the book, the most important I feel are:
- invest regularly
- diversify: “The more technologies you are comfortable with, the better you will be able to adjust to change.”
Both of these points go together, in that you should be investing regularly, but not just in a single topic. Read about new stuff in books, magazines, and on the internet. Try learning new programming languages and new technologies. All of these things work together in many different ways to make you a better developer. Take something like Ruby on Rails, with the sort of work we do it is unlikely that we will be doing a ton of work in Ruby on Rails, but if we learn how to work with it we may see some different ways we can approach the other work we do in more traditional languages. And, if suddenly all of our clients want us to use Ruby on Rails then we are in a much better position to respond to change.
#8: Invest Regularly in Your Knowledge Portfolio
However, we don’t want to just jump on any new technology that comes along just because it’s new:
#9: Critically Analyze What You Read and Hear
Section 6: Communicate!
Communication is a huge deal, especially since we are working with clients, so we need to constantly be working on improving. There is a lot of good info in this section so make sure to read it, but there are some especially good bits. It’s important to know what you want to say. Before a meeting or call, then think about whether it might be good to jot down any ideas you want to communicate, and plan for how you can get them across. And, think about who the audience is because you might need to communicate things differently if you are talking to a project manager versus talking to another developer. And don’t forget to listen. You may have something important to say, but communication needs to go both ways.
#10: It’s Both What You Say and The Way you Say It
Section 7: The Evils of Duplication
#11: DRY – Don’t Repeat Yourself
Duplication is bad, we all know it but often we lose sight of avoiding it. One of the main benefits of a technology like CSS is to avoid duplication, it allows us to express the styling of elements on a page in one place, so we don’t have a lot of duplicated width attributes or font size attributes throughout our HTML. I think we all are aware of the importance of avoiding duplication, but it is always good to have a reminder. Plus, there are some forms of duplication that we might not always recognize. This topic is definitely covered in more depth in the book, including multiple types of duplication so go through and read the book.
One big form of duplication is interdeveloper duplication, basically where different developers end up writing the same code. Probably the two biggest reasons behind this is that perhaps the developers are working on different projects and aren’t aware of what the other person has done, or that there hasn’t been enough care taken to make the code easily reusable so a developer chooses to write his/her own code even though something else may already be available.
#12: Make It Easy To Reuse
It is important to have some sort of code library that people can reuse code or contribute new code easily, so we can avoid this type of duplication. Essentially, “foster an environment where it’s easier to find and reuse existing stuff than to write it yourself.”
Section 8: Orthogonality
Orthogonality is a term that comes from geometry, and what it basically means in software development is to keep code independent of other code. Keep clear lines between the different types or purposes of code so things can be cleanly separated. A simple way of thinking about is, “Two or more things are orthogonal if changes in one do not affect any of the others.” If you are developing a frontend web application that handles a bunch of logic and integrates with Facebook and Twitter, then keep all of those things separated out from the others. If you need to post something to a user’s Facebook wall then keep that logic separate from the logic that responds to the UI (ie a button press). That way if the Facebook API changes (never!) then all you have to do is update the Facebook code, you don’t have to risk changing the UI logic as well. Or if the client decides to add another button to do the same sort of thing (Get Hotmail It’s Free), you don’t have to add duplicate logic for updating Facebook (and violate the DRY principle), you just call the existing code. All of this works together to make a better product at the end. A quote from the book says it best, “Once you learn to apply the principle of orthogonality directly, you’ll notice an immediate improvement in the quality of systems you produce.”
#13: Eliminate Effects Between Unrelated Things
This will lead to improvements in both productivity and reduced risk.
Section 9: Reversibility
#14: There Are No Final Decisions
I think this topic hits pretty close to home for us due to the nature of the type of work we do. We often run into situations where decisions get made and then are reversed later, so it is important for us to make things as flexible and as easily reversible as possible. Quite a few of the topics covered lead to code that is more reversible, but it still is important to keep the concept in mind as we’re making decisions. Especially, instead of making assumptions and writing code that is completely based on that assumption and will require significant work if the assumption ends up being wrong, we should do our best to think about what the possible outcomes are and what solution might be able to handle the highest percentage of those outcomes.
Section 10: Tracer Bullets
Sometimes we get projects that stretch the boundaries of our knowledge because they either use new technologies that are untested, or they push the limit of existing technologies to the point of whether we don’t always know the best approach immediately, and in these cases it can be useful to use a “tracer bullet” approach to projects. For anyone who doesn’t know, a tracer bullet is a type of bullet that leaves a visible trail behind it as it flies so the shooter can see exactly what path the bullet is traveling, particularly at night.
#15: Use Tracer Bullets to Find the Target
How this applies to software development is that it is “something that gets us from a requirement to some aspect of the final system quickly, visibly, and repeatedly.” What you do is build out bits of the structure at a time so that you can evaluate how things are coming and adjust quickly with as little work as possible if you need to.
Think of it like building a freeway, you plan out the route you want it to take and then start building the road. If you have a lot of information about the terrain and you know that there aren’t any problems then you can build the freeway section by section, working on the lanes at once. However, perhaps for some reason you are unsure if the terrain is right for a road, with the tracer bullet approach you would build out one lane from start to finish before building out the rest of the lanes. That way, if something happens and you need to change the path then you only need to fix one lane instead of all of them. Then once you have reached the end and you know you have a valid route, then you can build out the rest with much less risk.
In software development, it means that instead of trying to build all of the functionality for the entire project at once, you build out the project with limited functionality to a point where it is usable, and then start adding it the rest of the functionality piece by piece. The benefits behind this approach are:
- Users get to see something early, and see if they made mistakes in the initial design
- Developers build structure to work in: once that initial framework is done then it’s easier for developers to add more pieces of functionality
- You always have something to demo
- You have a better feel for progress
Tracer bullets don’t always hit their target, but they provide quick feedback to enable moving onto the target much easier than other approaches, on the right projects.
There is a lot more of the book I have yet to cover, so that will possibly (probably) come in a future entry, so keep an eye out for an update. Also, keep in mind that this sort of information isn’t the sort of thing that you can hear/read once and get it and not ever revisit it again. This is the sort of thing that you need to constantly keep in front of you and try to follow at all times, so please go and get the book and read it, and keep your own notes in front of you where you will be reminded of these principles while you work.