Time for a Personal Refactoring
Published on April 10, 2012
[a] disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior Code Refactoring - Wikipedia
As a developer, both career and hobbyist, refactoring is in my blood. I'm always looking for ways to improve existing code to improve its quality, testability, and maintainability. Refactoring is probably the most important technique any developer learns and one that should be constantly practiced on a daily basis. Without constant refactoring, code bases grow into massive, unmaintainable behemoths that often grace the front page of TheDailyWTF. That said, refactoring is hard in many ways, but none so hard in that it requires you to accept that with whatever you're building, you are probably doing something wrong.
Software as a field and an industry moves blindingly fast. Techniques, tools, paradigms, and even languages change on a monthly and even weekly basis requiring constant learning to keep up and to stay competitive in the market. Ideas that were Best Practices last month may be Anti-Patterns the next. New ways of thinking about problems show up daily. This doesn't mean your old knowledge is suddenly invalid, you simply need to keep adding more tools to your toolbox. Put another way, you have to constantly be increasing what you know and refactoring how you learn to stay ahead of the wave, or risk getting overwhelmed.
Now, I'm still relatively new to the industry -- I've been a professional developer for about six years now -- but I've come to realize through personal experiences and from others that the technical side of software development is only one part of this job, and a minor one at that. You may be a technical genius who can code circles around most other developers, but if you can't work with other people, if you can't effectively communicate, you aren't going to go very far. @brixen said it best recently in his talk Is Node.js Better that Programming is a behavioral science. I highly recommending reading the entire talk, but the gist is this: all software gets used by people, both who are technically inclined and those who aren't. Every line of code you write embodies your personality, and unless you never release any code you write, anyone who uses your code is interacting with you. It's vitally important to never forget this; who you are and how well you work as a team is at times more important than your technical chops, but how do you continue to improve here as well?
We need to refactor ourselves. We need to constantly be evaluating how we react to situations, how we communicate with team members and how we work with people we don't particularly know (e.g. clients of your product or users of your Open Source project(s)).
I'm not going to sugar coat this, as I'm writing this post more for myself than anything: this is very hard. As hard as it can be to keep up with what's going on technically in this industry, it's exponentially harder to recognize your own faults, much less to fix said faults. I have a tendency of being extremely hard headed and I know personally just how hard it is for me to recognize when I'm wrong, much less to have the strength to change my mind or how I act accordingly. As a developer I fall into the group of people who think extremely logically, and left unchecked this almost always causes issues.
Due to the nature of people and communication, it's impossible to take emotion out of any sort of communication, and this includes even the code you write. While you can't completely prevent anyone from taking offense to anything you do (this is the Internet, lets be real here), there are plenty of steps that can be taken to minimize potential conflict points, the first being how you communicate with your team-mates and users. What makes this particularly more difficult with technical minded people such as myself is we tend to think logically, without emotion, and with no hidden meanings. However it's unfortunately human nature to look for and find hidden meanings any and all communications. I personally need to be much more mindful of this truth in everything I do. What I do know is that the extra mental effort to ensure a given message isn't accidentally accusatory or blunt is much less than the effort required to fix problems such careless communications cause later.
So far what I've found that does help me is friends: friends who are willing to call me out when I'm being an ass and friends who understand who I am and who want to see me become a better person. It has taken a long time but I've realized now that I cannot fix or improve myself without help. I know I'm going to screw up, but as long as I have people around me who will tell me when I screw up, I'm sure I will make progress. In fact, I don't believe it is possible for anyone to become a better person without the help of others. Humans are social creatures, we can only thrive when we work and interact with others. With that, I'm taking the next step: improving my presence in the greater developer and Open Source communities.
As you've probably noticed by now, I've got a new website and a new domain. After working with Wordpress for a few years, which did the job just fine, to really rebuild and help people understand who I really am I've rebuilt my site from scratch. As a developer I like having complete control over what I'm doing and the tools I use. I've also learned to value simplicity and to abhore complexity, so a huge PHP site and a WYSIWIG text editor on a web page just isn't cutting it anymore. I've changed over to running a statically generated site using Jekyll, with the source of the site being available on Github. The design comes from the Jekyll Bootstrap theme built with Twitter Bootstrap. I can now work on the website using my two favorite tools: Vim (though right now I'm playing with Sublime 2 + Vintage Mode) and a terminal.
One huge benefit of having a static, simple website is that all of my work can now be pushed to Github. Why is this good? Because Github is my Resumé. I'm a huge proponent of Open Source and love how easy Github has made it not only in helping and contributing to existing projects but in starting and running your own, as well as making your work visible to anyone who's interested. The first place I go when I'm researching a new candidate or interviewee is their Gitub (Bitbucket, et.al.) pages to see if there's anything there and what they've done. In this industry, nothing speaks like code, because even if the person is the best communicator in the world, if they can't code at all, they aren't qualified for the job. But a great developer and a great communicator? That's what I want to be.
Along with the new website design, I've changed the domain of my website to jasonroelofs.com. As I get to know more people in the industry and more people get to either know me or start using my projects, I've ended up confusing people with my current pseudonym "jameskilton". It's not obviously a pseudonym, and it doesn't help that there are people out there who do have the name "James Kilton". I've also read that it's more professional to use your real name, though I'm not sure how much it matters these days. Either way I will be working towards retiring my old pseudonym, starting with a new website domain. I'll be updating Twitter and my email addresses soon. I'm not sure what to do about Github quite yet, as it's much harder to announce there that the account name is changing. Suggestions are welcome.
So hi! I'm Jason Roelofs. I love Ruby and I love Open Source. I'm extremely hard headed and can come across as an ass at times. I ask that you not take such incidents personally, but to call me out on it. Thanks!
blog comments powered by Disqus