I've seen a lot of really bad code lately. Not just bad code, but poor design, heavily coupled architecture and general anti-patterns. It's kind of a drag.
This is a pretty serious problem in my profession. With the pretentious sounding "software engineer" title slapped on jobs everywhere, you'd think that would imply great attention to detail and precision. That's definitely not what's going on.
It is absolutely true that, especially for folks like me who are self-taught, it's pretty easy to get started as a developer by hacking together something that barely works. I would even argue that if code never had to change, barely works would be an acceptable outcome. But real life, and this is more true than ever in a Web-based world, dictates that nothing is ever truly "done." It is destined to evolve and change.
The industry is suffering from a lack of people to fill the jobs for software development, and what people there are tend not to be great at what they do. That's not the end of the world, though. It can get better, but only if we as an industry get our shit together. There are plenty of things to do...
You can be a part of the solution to the craftsmanship problem in the software industry.
Hey Jeff! I'd like to offer a respectful but slightly dissenting view.
On many points I definitely agree with you. I think everyone should consider contributing to OSS projects, preferably in several different ecosystems. I can't think of many better ways of showcasing one's abilities, whether as a specialist with deep knowledge of a particular technology, or as a generalist able to navigate and learn from the best of multiple software ecosystems such as Microsoft, Java, Linux, Android or iOS. I also agree that mentoring and being mentored are vital to building an appreciation and aptitude for software development as a craft, and/or as an engineering discipline, rather than just a hack-fest devoted to pushing crud out the door.
Having said that, it's my experience that while good code requires good developers, bad or mediocre code isn't always due to bad or mediocre ones. Most developers work in companies whose core business is not software development, and in many such companies, network effects and time-to-market pressures are intense. It may seem distasteful to us, but it's simply fact that in many industries, the crappy product that gets to market first beats the elegant, flexible and sophisticated one that gets there second.
I also continue to believe, as we've discussed before, that there are no "silver bullets" in software development. TDD is a great tool. If used properly and skillfully it promotes productivity, clean design, separation of concerns, and refactorability. But in less than competent hands it can be abused in such a way as to do the exact opposite. I've now seen both of these things happen, in the same project (which you are familiar with) and sometimes even from the same developer. Neither TDD, nor any other tool I know of, can substitute for good architecture and design. Does that mean it's bad? Certainly not; but it tends to lead to good or bad results in direct proportion to the skill with which it is used, just like pretty much any other tool I can think of. And this is where both mentoring and experience come into play. And even the occasional diversion of reading StackOverflow or Slashdot or various development blogs (if your employer doesn't block them at the Web proxy level). Through some of these I became familar with BDD, which I now believe to be not so much a replacement for TDD but a complement. TDD largely tests implementation, which has both pluses and minuses. BDD tests behavior. It tries to ensure that your business requirements themselves are written in such a way as to be testable. Then, once not only your unit tests but your business tests (a superset of integration tests) pass, you have freedom to refactor and optimize, with the assurance that once done, your implementation AND the business functionality, which is after all the whole reason for all those implementation details to exist, continue to work properly.
Jeff, I believe that a developer who wants to remain relevant is *always* looking for ways to do things better. Change is the only constant in this business. Adapting and making yourself maximally valuable can sometimes involve people skills, not just technical ones.
I don't look for excuses. I look for opportunities to improve. I saw working with an experienced TDD practitioner as just such an opportunity, and tried my best to do so. It turned out to be a valuable experience. In the end, I continued to see TDD as a great tool, not a religion. But now I know how to use it effectively in an environment that supports it, and whatever our disagreements, I appreciate your role in helping to bring this about. Now as for people skills: no one would claim mine are perfect, and at times that's held me back. But I'd like to think they have improved over the years. One thing I try very hard not to do is to assume people who disagree with me, or don't know as much as I do, are idiots. I've found that I learn a lot more from those with whom I don't agree, than from those with whom I do. I've also found that treating people with civility, courtesy and respect - even if in some cases I don't feel they have completely earned it - usually works to the advantage of everyone concerned. Finally I've learned not to take the disagreements personally. Argue it out, make your case, get mad (temporarily), do whatever you have to do. But then buy your opponent a beer, or let him buy you one, and laugh about it later. Life is too short to be pissed off all the time. Rant if you wish, but then make peace with it. Get mad at people if you must, but then make peace with them.