To that end, I'm going to discuss a fundamental part of my mentality as a programmer, rather than something recent I've been working on. Something to get the juices flowing, so to speak.
As a young programmer, I found myself in a position leaving college that I'm sure many others have; the languages taught in school, and the methodologies, do little to promote coding in a modern environment. Stress is placed on getting things to compile and show off coding concepts like recursion rather than things like code cleanliness and readability. The concept of 'extreme programming' is largely absent from the college experience, or at least, it was from mine.
My first job involved C#, a language I had no experience with. As a Computer Engineering student, I took classes in C++, but my senior level projects were in straight C, and run off of a microprocessor that could handle little else. I was given time before my start date, shipped the latest O'Reilly book on C#, and told 'read this. See you in 2 weeks'.
I immediately loved the language, and felt it threw away a lot of what I found cumbersome and painful in C/C++ (header files, unmanaged third party libraries just to do things like string concats, etc), and the advent of 'true' OO brought, or at least made me feel at the time like it brought, so much clarity and understanding. I briefly entertained going back to school at a later point, this time for game development, and the nail in the coffin for me was the loss of managed code: I certainly CAN code at a lower level, and have in the past, but is it something I want to do on a daily basis? Certainly not, and games are rarely/never written in a higher language than C#: the clock cycles in today's consoles are too valuable to rely on something like the CLR. So that was that.
My first boss was a fan of extreme programming, and taught me it is far better to write code that is human readable. A great baseline to share: if what you are writing requires a comment to explain what it is doing, you might be writing it wrong. Hopefully even someone without programming experience can understand at least the concept of the line:
Ball.Roll(10, DistanceUnits.Feet, Direction.Left);Certainly better than:
b1.Do(10, "f", 0);Hopefully you see where I'm coming from with this. Naming is not just a good idea; it can be essential, especially when you have to pick the code back up in a year and make changes. The learning curve on your code is your own responsibility to maintain.
Two things changed my mentality drastically: a program called ReSharper, and a book called "The Pragmatic Programmer". The former is a wonderful piece of software with dozens of shortcuts and helpers for cleaning up code and writing boiler plate quicker. If you have to choose one single VS tool to always have when writing C# code, this is it. At first I resisted many of the 'auto cleanup' suggestions, then slowly I gave in to them as a saw the good folks over at JetBrains are pretty darn smart, and when the make a suggestion, chances are they are correct and you are, in fact, incorrect for disagreeing with them. Some of it is style and flavor, so I leave those decisions to you, and the program is not perfect (there are, for example, some bugs with ReSharper suggestions in Moq when using parameters with null defaults in mocked calls), so all I can say is give it a shot, consider the suggestions even if you don't agree with them, and it will make your code better over time.
The latter, "The Pragmatic Programmer", is a book full of axioms to keep in mind when writing code. It does a fantastic job of making you think about the responsibilities of your classes, where knowledge should live, how data should be communicated between objects, etc. While the verbiage can be a little 'odd' at times, I found the core concepts to be incredibly helpful. In fact, when I finished it I printed the 3-page bullet list at the end of the book of all the things to keep in mind and stuck it above my monitor. Every now and then, I would give it a quick glance and say 'am I following these concepts?'. Sometimes I was, and sometimes they caused me to go back and revisit code I had previously dubbed 'QA ready'. (Never say 'complete'. Software is never complete. Nothing is sacrosanct, everything can be changed, improved, and rearchitected.)
I wish I could go back and convey the things I know now to the young programmer just out of college. I would love to revisit code that was shipped with glaring issues in architecture, to clean it up and add all those features that at the time were 'impossible' simply because of the way it was put together. I think of the responsibilities on that fledgling programmer, and how the end result is nowhere near what it should have been given the importance of the code. But that is reality; software goes to market with glaring bugs, security holes, and inefficient processing cycles. Sometimes fixes come, other times they do not. Features are given up or compromised in the face of developer limitations. These things happen, and are accepted. No one can be perfect, everyone will make mistakes, and the code will evolve. The biggest sin is the developer who cannot, or worse will not, evolve and better himself, learn from his mistakes, pick up on the lessons his peers and mentors and even random voices on the Internet are whispering to him. Programmers, like the code they write, evolve or die. Languages are born faster than any normal human can master them, and concepts are deprecated before they are even released. It is a daunting and ultimately futile task to try and keep up with it all. The code monkey is young, generally: you become a manager, or an architect, and move away from the rat race. Either way, you leave the code behind, and the mastering of the constant influx of new technologies to the next generation. That's not a requirement of a programmer's career, obviously, but it is the goal of many. Those that do not either become the rare pinnacles of their chosen fields, or stagnate and find the niche markets of large companies who similarly refused to evolve. That's not to say that's a "bad" career choice, because many of these experts of lost technologies can command exorbitant fees for their skills. But is is a move away from the next generation, an acknowledgement of the inability or unwillingness or even lack of interest in adapting to the technologies of tomorrow.
As always, I welcome people to weigh in on my thoughts. Until next time, happy coding!
References:
The Pragmatic Programmer
ReSharper
No comments:
Post a Comment