Before setting the resolutions for the new year, I thought I’d go over some of the main takeaways from the previous year related to developing software in a more structured and organized way.
Things I learned in 2012 Software Development
Formal education is great. Self-education is better.
In August of this year (2012), I finally graduated from Brigham Young University: Idaho, and earned my Bachelor’s degree in Computer Science. If I thought I was well educated in the subject when I first started my studies there, then now, in contrast, I should consider myself the ultimate software engineer. In other words, I didn’t really know a whole lot when I first started, and now I know just how much I don’t know.
Having gone to school and lear
However, with all this said, now that I’m out of college I don’t have any home work to turn in, I can see how quickly my formal training, even with every day usage and application from a full-time job can become outdated. Unless I continue to read up on the latest research, bleeding edge techniques and technologies, and study and apply, not just new concepts and technologies, but more of the existing ones, I will gradually and steadily become outdated and less useful.ned software engineering principles in a more formal way really helped me to realize all the bad habits I had from learning everything on my own. It also taught me the difference between, say, a coder and an engineer. I really learned the discipline involved in building great software, as opposed to putting together a bunch of functions that somehow work together to output something that seems to work in the one general use case that the application is intended for.
Thus, as powerful and helpful as a formal computer science education is, the education I involve myself in on my own is much more valuable because it will never end. And it will never end because there is too much to learn already, and each day, as the discipline itself continues to grow and progress, there is yet more I should learn and become familiar with.
Good tools are important. Knowing what tool is right for the job is more so.
With so many tools already available, and with new tools coming out every day, it becomes harder to choose a given tool from all the other competing tools. With so many tools to choose from, it is also very easy to choose the wrong tool. By a “tool” I mean a certain type of software, a framework, a library, a design pattern, etc.
The best way I can summarize what I learned in regards to this topic in 2012 is with the following phrase:
Just because you can, doesn’t mean you should.
Just because a lot of people (co-workers and bosses included) do something a certain way, or don’t do something they should, or follow whatever trend, etc., it doesn’t mean that’s the right or best way to do it. Or just because they use a set of tools because they have always use them, doesn’t make the tools the most appropriate for the situation.
Knowing a little bit about almost everything is good. Knowing almost everything about a little bit is better.
With so many awesome aspects of computer science out there, it becomes difficult not to at least try out a few things here and there. How many people do you know that can tell you at least a little bit about most topics out there: web development, mobile development, databases, 3D graphics programming, hardware, software development, quantum computing, software factories, software synthesis, so on and so forth…
While there is nothing wrong with being curious about many topics, professionally, I believe it is better to be curious about many topics, but fascinated and personally invested in only a few. It is better to be among the very best front end developers, while knowing a thing or two about what is going on in the backend, than knowing only the trivial parts of both. This is my view on the specialist vs. generalist issue.
Learning is good. Sharing what you learn is better.
While this is something I believed in before 2012, during the last 12 months particularly, I have come to the realization that I can learn so much more, and remember the most important takeaways from what I learn when I document the learning process (what I learned, how, why, etc.). Better yet, whenever I try to teach what I learned, I very quickly find out the points about it that I still don’t quite understand, or just how important or insignificant a certain aspect of it really is. If I try to explain something I just learned (or even something I already know), and the listener doesn’t quite get it, then chances are that I’m not very well versed in the subject myself. I have found that unless I can summarize a subject into a very brief and succinct sentence, then I still have some learning to do about the topic. And the more I can come up with summaries of varying depths about a concept (a very brief overview, a slightly longer introduction, and a full on, detailed explanation, etc.), the more I in fact know and understand about the matter.
Becoming better is good. Making others better with you is best.
Earlier in 2012, I was given the opportunity to go from a lead developer in the company I worked for, to being the department manager. This gave me the opportunity go from leading a project or two, to being able to coach and mentor other developers. From interviewing new candidates, to working with junior programmers, this experience showed me that the most fulfilling and satisfying part of being a part of a team is to be able to help others grow.