Of all the conversations I find myself having over and over in this field, I think more than anything else I've been a broken record convincing teams not to adopt GitFlow.
Vincent Driessen's post "A successful Git branching model" -- or, as it's become commonly known for some reason, "GitFlow" -- has become the de facto standard for how to successfully adopt git into your team. If you search for "git branching strategy" on Google, it's the number one result. Atlassian has even adopted it as one of their primary tutorials for adopting Git.
Personally, I hate GitFlow, and I've (successfully) convinced many teams to avoid using it and, I believe, saved them tremendous headaches down the road. GitFlow, I believe, leads most teams down the wrong path for how to manage their changes. But since it's such a popular result, a team with no guidance or technical leadership will simply search for an example of something that works, and the blog post mentions that it's "successful" right in the title so it's very attractive. I'm hoping to possibly change that with this post, by explaining a different, simpler branching strategy that I've used in multiple teams with great success. I've seen GitFlow fail spectacularly for teams, but the strategy I outline here has worked very well.
I'm dubbing this Three-Flow because there are exactly three branches1. Not four. Not two. Three.
Here are five more Guiding Principles I use when making technical decisions as a software engineer. You can also check out Part 1.
Just as before, this list is really a list of principles I use when making difficult technical decisions or mantras I use to snap myself out of being stuck - it's really not about just how I try to write good code (SOLID, DRY, etc) although there is a little bit of that as well.
Perfect is the Enemy of Good
When it comes to designing code, I think it's better to get started as soon as possible and make changes and modifications via refactoring as needed. It's better to get something up and working quickly, rather than spending time debating in front of whiteboards about the correct way to do things. In my experience, engineers in particular have such an affinity for elegance that we can get wrapped around the axle trying to figure out the perfect, most elegant solution.
I'm not saying to write shitty code, obviously. It's still important to follow good design principles like SOLID, the Law of Demeter, KISS, defensive programming, CLEAN, separation of concerns and so on. It's just that you don't have to get every little thing perfect, it's better to get something that's imperfect but works built and then refactor to perfection later.
I find that I repeat myself often at work. There are a handful of things I say so often when discussing decisions that I've been called out for it on occasion for acting like a broken record.
But the reason I keep repeating these phrases is that I think they inform a great deal of my decision-making. They are, in effect, my guiding principles when developing software professionally.
I thought it might be fun to write a few of these things down because I think that they're worth sharing - I feel like these principles have steered me in the right direction time and time again. Obviously, there are exceptions to these and there are times when they should be ignored (after all, not being a zealot is one of the principles) but I think they will generally take an engineer down the right path.
Have Strong Opinions, Weakly Held
I think the phrase I've heard more than any other in my life is "tell us how you really feel!" which is I guess people's way of telling me I've made them uncomfortable by expressing an opinion too aggressively. It's true, I can be very strongly opinionated, and I've gotten into more than my fair share of, oh, let's call them "passionate discussions" in the workplace. I'm never insulting or personal, but I have strong opinions on how to do things.
At work, the BigWigs paid for a bunch of employees, including myself, to take the Gallup StrengthsFinder test. This test gives the taker a series of choices between two things that aren't exactly opposites, and you have to select which one you identify closer with. In the end, the test tells you which of 34 possible strengths are your top 5.
I enjoy taking personality tests for fun, but the way that the aforementioned BigWigs were attaching tremendous levels of importance to the results of the test made me a bit weary. Personality tests can often have a horoscope vibe, where they all say something so nice about the taker that everyone who reads it says "yep, that's me!".
So before the test, I took a look at the 34 possible strengths that the test would identify. I figured they'd all be things I liked, so that when the top 5 were output, the taker would like the results. To my surprise, there were a number of strengths, about 10 of the 34, that I would have been downright irritated if they appeared in my top 5. To an extent that, if the exercise told me any of those 10 were strengths of mine, I'd be able to instantly disqualify the test as bunk.
So I took the test with a skeptical eye toward it, but I was actually incredibly surprised by the results. I think the test absolutely nailed me, and I'm so impressed by the accuracy of my test results that I think it's worth sharing here. These strengths are ranked from strongest to less-strong (I don't say weakest because it's only the top 5 of all 34 strengths, so all 5 are very strong).
Wow, this Machete Order thing got big! After the post first "went viral" and got mentioned on Wired.com, I started getting around 2,000 visitors to it per day, which I thought was a lot. But then in the months before Star Wars Episode VII: The Force Awakens was released, it blew up like Alderaan, peaking at 50,000 visitors DAILY. This year, over 1.5 million unique users visited the page. It's been nuts.
So let me start out by thanking everyone for liking and spreading the original post - I'm truly floored by how well-received the post was. Considering I wrote a nearly 5,000-word essay on Star Wars, I'm pretty amazed that it was only a handful of times someone told me I was a loser neckbeard who needs to move out of my parents' basement and get a girlfriend (I'm married with a kid by the way). People only called for my public execution a couple times. On the internet, that's the equivalent of winning an Oscar, so thanks everyone!
In all seriousness, I've had thousands of people tell me I "fixed" Star Wars and made the saga more enjoyable for them. I think this is an unnatural amount of praise - after all, I'm just a guy who watched some movies in the wrong order and skipped one, then wrote down why. I didn't create fanedits or anything truly difficult like that. But at the same time, the reason I published the post in the first place was that I felt Machete Order "fixed" Star Wars for me personally, allowing me to use the relevant parts of the Prequels to make Return of the Jedi a better movie, so it's really awesome that so many other people felt similarly. All joking aside, thank you.
Since it's been about 4 years since the original Machete Order post, and now that Episode VII is out, I thought I'd post a small update answering a lot of the questions I've been asked and responding to the most common criticisms of Machete Order. There will be no spoilers of Episode VII here, though I will be talking about it a bit and I can't predict what people will post in the comments, so if you haven't seen it yet, make like a Tauntaun and split.
It's been a long time since I posted about how school is going, and I figured the folks who read my blog (all two of you, hi Mom!) might be curious.
Since the end of my Spring 2013 semester, I've been in "Research Phase". This means I'm finished with classwork and have been working on my research project. It's been a little over two years now, so here's what has happened.
Picking a Project
About two years ago, I started working with my advisor trying to figure out what area my research would be in. I've always had a fascination with Genetic Algorithms and Metaheuristics, so I knew I wanted to do something involving that subfield. Two of my projects at school utilized Genetic Algorithms, and I had a lot of experience in the area.
I went back to school to primarily focus on CS Theory & Algorithms, but I knew my biggest strength was Software Engineering. In other words, I like theory, but I'm not sure I'm a real theoretician, and I wanted to play to my strengths a bit. This meant I wanted to be writing real, working code, rather than proofs. If I wound up proving anything interesting, that'd be great, but I didn't want that to be part of my critical path to completing my PhD. Lots of CS PhD's go off with a white board and paper and output some amazing results, but I knew that wasn't going to be me.
I work with Grails a lot and while I really enjoy it for the most part, there are definitely some weird quirks of the framework.
One such quirk is something I encounter whenever I want to write unit tests against grails controller methods that render out templates directly. This isn't something I do very often - generally I prefer rendering out JSON and parsing it with client-JS - but in some cases when there's a lot of markup for a page element that you want to be updateable via ajax, it makes sense to render out a template like
render(template: 'somePartial') directly from a controller method.
Unfortunately, these kinds of methods are very difficult to write tests against. While a normal render exposes a
view variable that you can test against, for some reason using a render with a template doesn't seem to do this.
I've seen lots of solutions where you stuff a fake string matching the name of the template using some metaclass wizardry, but then you're stuck dealing with some semi-view stuff in what you might want to simply be a unit test about the model values placed by the controller method.
My default yearly conference, for many years, has been UberConf. I really enjoy UberConf because it's packed full of lots of great sessions, and it's conveniently local. However, because I go to various local user groups and attend so often, I find that, if I go two years in a row there are too many sessions I've seen before, and I wind up disappointed. So for the past few years, I've been alternating between UberConf and something new. Two years ago, it was OSCON, and this year it was QCon New York.
I chose QCon for a few reasons. One, the sessions seemed very focused on architecture and higher-level concepts, with very few language/technology talks. This was right up my alley because, while there are some languages and tools I'd like to go deeper on, I think a more significant area for improvement for me is architecture and scalability. We get tons of traffic at my job - more than any other place I've ever worked - so I've had to learn a lot about scalability, and the nature of the work has forced me to really see broad system design differently.
I went to QCon specifically wanting to improve some areas where I was weak, namely containerization, microservices, and reactive programming. I hear a lot of buzz about these things, and they pop up on recent ThoughtWorks Technology Radars, and QCon seemed to have a lot of sessions to offer in these areas. It took a LOT of convincing to get my employer to agree to send me to a conference location as expensive as New York, but eventually they approved it. Here I will detail some of my thoughts about the experience, in case it may be of use to others considering QCon.
This blog was never intended to be popular by any stretch of the imagination. Largely I started it simply to have a place to gather solutions to technical problems I've encountered, so that I could easily look those solutions up if I needed them again. The blog has always run on my own shared hosting server, on a self-installed version of Wordpress.
To my great surprise, a few of my posts have found their way to the front page of reddit. My post about Star Wars has been mentioned on King of the Nerds and The Big Bang Theory, and even landed me an Interview on NPR.
Needless to say, the traffic to my blog has been both extremely unexpected and unpredictable. The Star Wars post had been online for months with virtually no traffic before Wired suddenly linked to it, instantly decimating my web server. I've fought and fought with various configurations for Wordpress, used as much caching as possible, and even had my web host temporarily upgrade my service, all trying to keep a web site that makes no money online even when traffic increases by a factor of 100 overnight. When my site goes down, it's embarrassing, because even though it's just a personal blog on a shared host, it gives the impression that I, as a software developer, don't know how to make a web site scale.
Switching to Jekyll
So after the most recent pummeling I took due to a Hacker News link, I decided it was time to bite the bullet and convert the entire site to Jekyll. I've messed around with the technology before to build another, smaller, blog, so I was somewhat familiar with the constructs and idioms. A lot of work and ten custom plugins later, the entire site was converted, with very little loss of functionality.
When I graduated with a Computer Science degree ten years ago, I was excited to dive into the world of professional programming. I had done well in school, and I thought I was completely ready to be employed doing my dream job: writing code. What I discovered in my very first interview, however, was that I was massively underprepared to be an actual professional programmer. I knew all about data structures and algorithms, but nothing about how actual professional, "enterprise" software was written. I was lucky to find a job at a place willing to take a chance on me, and proceeded to learn as much as I could as quickly as I could to make up for my deficiencies. This involved reading a LOT of books.
Here I reflect on my 10-year experience programming professionally and all of the books I've read in that time, and offer up the ten that had the most profound impact on my career. Note that these are not the "10 best" programming books. I do feel all of these books are very good, but that's not the only reason I'm selecting them here; I'm mentioning them because I felt that I was a profoundly different person after reading each than I was beforehand. Each of these books forced me to think differently about my profession, and I believe they helped mold me into the programmer I am today.
None of these books are language books. I may feel like learning to program in, say, Scala, had a profound impact on how I work professionally, but the enlightening thing was Scala itself, not the book I used to help me learn it. Similarly, I'd say that learning to use Git had a significant impact on how I view version control, but it was Git that had the impact on me, not the book that I used to teach myself the tool. The books on this list are about the the content they dumped into my brain, not just a particular technology they taught me, even if a technology had a profound impact on me.
So, without further ado...