July 29, 2015
I love learning. I think most people who treat what they do as a craft love to learn. There is just something so satisfying about becoming a little bit better every single day.
If you have heard of the learning pyramid or the cone of learning, you know that teaching has a very high level of retention. There are differing percentages and views on this pyramid, but the concept remains.
This is why I think every developer should teach and mentor. I think that my drive to teach and help has been one of the biggest contributing factors toward me knowing what the hell I am talking about.
Seriously, if you think you know something well, find someone who doesn't and try to teach them. My first few attempts at teaching were awful. I was terrible at it.
Someone who is just starting on a topic will ask you questions about things you either took for granted or had never even thought about. This left me scrambling many times for words to explain something I thought I knew.
This leads to the oft used Einstein quote.
If you can't explain it simply, you don't understand it well enough. - Albert Einstein
This isn't to say you shouldn't try to teach if you're not an expert. I mean to say that teaching is the fastest way to expertise and mastery. You may also find that the closer you are to someone's level, the more you gain out of teaching them.
A while back I had convinced my friend who used to be an English teacher to try this programming thing out. He is insane, so he went for it. Trying to guide someone into software development from scratch was one of the most challenging teaching tasks I have ever taken on. He has been putting in a lot of hard work and is now a full time associate software engineer. You can view his site here.
I had taught people various technologies and patterns and methodologies before, but nothing of this scale. I really had to grow into it and still have a long way to go.
You'll find that after you get some practice, you are able to organize your thoughts and words much better than before. You'll be aware of your knowledge gaps and you'll be a better communicator for it.
Teaching others has given me a huge advantage and I intend to do it as often as I can.
July 22, 2015
Chess is an awesome candidate for test driven development. I have been working on a chess application sporadically for a couple of years, which is evident in the date when I first announced it: Original Blog Post
The rules on movement are entirely defined and so you have a lot of easy initial cases to setup.
The problem though, is that you basically have an infinite number of permutations of movements and boards to test for. That fact made this test coverage thing pretty daunting for me.
The thought of manually setting up the board and pieces for every single test I wanted sounded pretty awful. I thought about the nature of validating any given move and decided that I could just play a chess game against myself, capture the board and move command, declare whether the move is legal or not, and give the dataset a name.
So I coded it out and now have a user interface for playing through a game and capturing test cases.
I then needed to put together a way to run the test cases so I coded out the consumption of the test case JSON files and fed them into my move validation code.
I put together a simple table to display the result. For an extra treat, for any failed tests, I reused my angular chess board to display the board state and offending move. That way I can switch between any failed tests for a visual representation of what I need to fix in code.
Now I just need to play a few sets of games against myself while trying to do some seriously whacky things and I'll have fairly comprehensive test coverage.
If you're interested in checking out the code:
Chess Sharp github repository
I think I'll now work on refactoring this entire chess application now that I have tests that tell me whether or not it works.
I think that there are a lot of different situations where testing through state snapshots can really speed up generation of test cases.
Maybe when I find a good real world use case I can share that too.
July 15, 2015
Companies that support remote workers and do it well seem to have a huge leg up on the competition.
They prioritize communication and collaboration by necessity
They reach out to include all parties in meetings and events. The organizational structure is inherently built to be inclusive because you couldn't get work done effectively otherwise. In an on-site environment there is so much verbal communication, that it wouldn't be feasible to share it with all relevant parties. In a remote culture your "hallway conversations" are saved in your messengers, so you can easily pull out the essence of your conversations. Facilitating this information sharing in a remote culture can create a lot of white noise in email and meetings, so organizational structures like the Incident Command System tend to arise naturally. I would say that on-site workers benefit from this more efficient communication structure too.
It is easy to reach out for help
It is easy to reach out to anyone because all it takes is a non-intrusive email or message, which you can follow up on several times without being as blatant as barging into some office or cubicle, just to have a chat. Then there is an inherent reminder list for each of us to get back to people who have reached out to us. You can also think a bit more on how you want to ask for help, so that you don't sound like a fool.
There is a lot less wasted communication
We tend to think more about what we say when we need to take the time to type it up. What we do communicate is automatically documented and can be referred to directly, instead of playing telephone with the original message. Even if we are over-communicating, it is okay, because we aren't forcing a squadron of employees to sit in a meeting room pretending to be interested. If you're only partially needed or interested in some meeting, you can attend, but still get work done.
There is a lot less posturing
The lack of posturing is something very refreshing. I have to believe that it has something to do with the fact that most of the effective communication is either written, or is done in large meetings where lots of people are watching. Whatever the reason is, most of the communication is about sharing knowledge and hashing out problems and not just personal advancement. Because we can't rely on body language and subtle dominance tactics, we need to present our ideas with logic and favor for the common good.
There is often a higher caliber of workers
This is another point that I can't fully explain, but I would say that because there is no geographical limitation, you get to pick the cream of the crop from anywhere in the world. I would say that it takes an especially focused and driven individual to succeed in a remote environment, so filtering out the fluff is a necessity. You need to be organized and you can't hide behind meetings and the work other people do as easily. There is a pressure to be on, because you want to be sure you're known as a hard worker. There is this stigma with remote workers, where everyone talks about how easy it is to slack off, which really just means that the onus is on us to disprove that. It also means that I can work my butt off, but didn't really need to put pants on in the morning to do so. I wear pants though, that was just an example.
You get a huge portion of your life back
Say goodbye to commuting and gas costs and rush hour and car maintenance costs and the time consuming morning routines. Time is money and not needing to commute is a seriously helpful perk. The company is rewarded with you being happier and likely gets another half hour to an hour of real work out of you.
I mean, some people spend HOURS commuting every single day.
If you spend an hour a day commuting,
that is 250 hours a year you've lost to the asphalt rivers of doom (1 * 5 * 50).
You could also hear that as more than 6 forty hour work weeks.
Here is the average one way commute time for someone in the US: United States Commute Times
They tend to be more flexible in general
Any company who is flexible enough to do a good job at supporting remote workers is likely a company that respects that life happens and people may have shifting schedules. My experience has been that I have been able to be a lot more productive and less stressed in the rest of my life due to working for a good remote organization.
Chicken or the egg problems
The mystery to me here is whether striving to have a great remote culture encouraged the organization to be excellent, or whether the organization had to be excellent in the first place to create a successful remote culture. Either way, it seems that good remote companies tend to be far above average as far as effective companies go.
I don't think I'd be satisfied working for a company that didn't make remote workers a priority. They just seem to have the other priorities straight as well. If you get the opportunity to work for an organization that promotes a remote culture, I highly suggest giving it a try.