A Mighty Wind – One of my favorite movie scenes

The scene of Eugene Levy standing in the grave for the album art on “Calling it Quits” still stands as one of my favorite comedic movie scenes of all-time; the sort where you can’t describe it without laughing. I figured with 2016 being over it was worth sharing a Mitch Cohen moment.

So You Think You Can Freelance?

The life of the technical worker has never been better; they have strong salaries, low unemployment, challenging work, and modern black t-shirt benefits like ping pong, stocked kitchens, and flexible working hours. That doesn’t mean it’s perfect though and the media continues to detail the upward freelancing trend in the marketplace predicting 40% of the workforce will be freelancers by 2020. Will we be 100% freelance someday? Of course not and I suspect these stories are overplayed as I would have expected TaskRabbit to be in Minneapolis in 2014, or 2015, 2016, please give me TaskRabbitMPLS in 2017!

I think freelancers are wonderful for tech needs and I use them often for systems, DBA, and IT support work; any area where the level of expertise I need is greater than the skill set of my team or more commonly where resource constraints exist. It gets work done fast, done right if properly managed, and allows us to learn and scale simultaneously.  My past position in corporate IT even drew me to this model with hiring for full-time positions by starting as a contractor for 3-6 months as a test drive for both parties. Hiring is hard and if the super-tech HR systems for talent identification aren’t in place I would much rather do a contract-to-hire then do a straight hire; I think it is fairer to both parties as it allows time to feel each other out.

Okay, Okay. So you think you can freelance in the tech scene? I bet you can! If you are considering a move then here are some considerations for you to bring into your brain-space when you are making the choice.

  1. Why do you want to do this?
  2. What do you do well?
  3. Who do you know?
  4. How do you plan to charge?
  5. Are you a business?

Why do you want to do this?

Tech life has never been better. The marketplace is strong, tech is central to most of the domains out there and the offshore focus from the aughts has withered on the vine for most of us. Techie life for the full-time worker is solid, so how could it get better? For some its roles and responsibilities and career growth at your current employer but perhaps the grind of your workplace has reached a tipping point and you want to go independent, either for the chance of higher earning power or just to do something new and interesting. Whatever the circumstance know your why.

For me it was the opportunity. I had come back from my experiment in the wine-making world and joined my buddies startup to run the tech but our funding was so low I had to compliment my income with some side work. That’s what led to me starting my consulting company and 8 year run as a consultant. My why was opportunity and taking a leap.

What do you do well?

Its so important to know what you do well and what you don’t do well and then how you can market that story in your new venture. Are you an expert in a legacy stack like ColdFusion? Are you a user experience ninja? Product management, MySQL DBA, architect, AWS, training, etc. There is something you do well. I was raised in a project shop that worked on large accounts in e-commerce, CRM, CMS, and custom dev so I was able to consistently touch diverse areas and was always involved in the client meetings because one of my core skills is the ability to speak to the business and tech. When I started consulting I looked for projects where I could help be that bridge and lead the product/project to launch.

Related to this is what you don’t do well or what you don’t want to do. While I’m good at diagnosing the root cause of an issue I don’t support. I prefer spending most of time with the big picture view rather than being heads down all day coding. Most in our field are the opposite, figure out which you are and look for clients, roles, or contracts that fit your style. There is always more demand and flexibility for the heads down roles then there is for leadership roles and it’s a different sales strategy as well.

Who do you know?

So, really, who do you know? Also known as how are you going to find work? I was fortunate that my friend suggested I walk the path I did, he is much more of risk taker than I and saw that the risk was actually low and the need was high out there given my skill set and network. And he was right because a majority of my clients were either past colleagues or former clients! If you don’t think you have the network for that then you should consider focusing on contracting. In my terms, contracting is when you work with a recruiter or placement agency to find you contracts of variable length and compensation. That is how the majority of independents work. It’s a trade-off, outsourcing the client acquisition for a fee to the recruiter. My experience was as a consultant, again in my terms, that was where I found the client and made the sale either on a bid or time and materials basis, no middle person. The client acquisition process for a consultant is long and expensive but the hope is that your investment pays off for both sides via a long-term relationship measured in years and the financial upside is far greater.

A talented freelance coder easily can earn $100 to $200 an hour. –wsj.com

How do you plan to charge?

If you’re a contractor you will be talking in terms of rate. There are two points of negotiation there, the rate you are paid from the recruiter and the rate they charge the client. Your challenge is to understand the difference and work to know all the data. That delta between the rates is what the house takes and the recruiter may be incentivized to maximize that gap (often the case). Recruiters are well versed is discussing rates and odds are you are not; expect to feel some level of discomfort the first time you explore this area, it’s okay, work through it. One of my first experiences was where a recruiter was trying to pay me $35/hour and at that time I didn’t know rates but I knew it felt really low for my level of self-perceived talents! I ended up passing because it just didn’t feel right, eventually you’ll learn rates. Also, there are shops that are transparent with their practices and will just tack on a flat fee to your expected rate…if I were contracting that is who I’d work with. In Minneapolis that would be a shop like DevJam.

If you are a consultant you have more options. Rate or time and materials is common and I would bill monthly. Over time my rates got quite high and some clients wanted a price break and for them I offered blocks of hours that they could purchase at a reduced rate, this worked because I was prepaid and was willing to take in a bit less for a happier customer and reducing the rate of payment default. Earlier in my career I worked more on a project basis where I would bid on work with written proposals. That is normal for most consulting shops of any size but given my solo focus and lack of interest in growing into a consulting shop I moved away from those. Either way you will have times where you are uncertain if you can charge a certain dollar amount or if you should discount in order to ‘secure’ the work. To that I say good luck, it takes reps and resolve and there isn’t a crystal ball; just know what you are worth.

Are you a business?

You better be! My dad owned a bar and restaurant when I was growing up and Minnesota had Dram Shop rules that made it a bit too easy to bring lawsuits against providers of alcohol.  My father let me know the importance and necessity to separate business assets from personal ones. You won’t be subject to the level of risks as a bar owner but you should still protect yourself and besides its easy. Go to your state’s department of commerce website and register yourself as a LLC. Yes, you can overcomplicate it and go to Delaware like the startup sites will advise but why make it hard. I advocate to keep it all easy; spend the $50 and come up with a basic name that won’t cause embarrassment. I used JD Laboratories because my first two initials where “JD” and I had a chemistry degree in addition to computer science so I thought that made me sound smarter, perhaps, who knows it was way back in 2004!

Next, use a credit card specifically for business expenses, it’s so much easier when you do bookwork. You can also set up a business banking account if you want or use Quicken, Quickbooks, Freshbooks, etc for invoicing and tracking your P&L (Profit and Loss). This can easily be used to fill out our schedule C on a tax return. You could go with a S corp and do a corporate tax return but IMHO its much more a pain then it’s worth unless you have employees and real growth potential…but this is just to be independent!

Good luck with your endeavor. I had 8 years of consulting that were professionally enriching. In the end I went back to the workforce as I was more intrigued with the roles and responsibilities part of the equation that larger orgs offered. But consulting bought me a house and my masters in software engineering, brought 3 startups, offshoring experience, travel and a ton of pride at being self-employed.

My 2016 Annual Review

I decided to take a cue from James Clear and write my own Annual Review. As James states: “The process reminds me to look back on the previous twelve months, celebrate my victories, evaluate my failures, and hold myself accountable in public.” I think it’s a solid idea that will take my consistent internal dialogue on self-performance and put it to paper…assuming I print this!

So the format is that the 2016 Annual Review will answer the following three questions.

  1. What went well this year?
  2. What didn’t go well this year?
  3. What will I be worked towards in 2017?

1. What went well this year?

2016 was a big year! I had so much more time on my hands after finishing my MBA in 2015; did I put that time to good use?

SaaS cloud migration. 2016 had me focused on moving our systems into AWS. We spent most of 2016 running a cloud/physical data center hybrid and are a few tasks away from being 100% in the cloud. There is plenty of work to continue on with our AWS architecture so we can be even more distributed, be better prepared for failover, and improve our CI/CD approach. Working is SaaS in today’s techscape is glorious!

New products and team improvement. I roadmapped the release of two new products in 2016. One is an entirely new BI stack as a Tableau partner and the second is a release of our new flagship SetSight product…all distributed, restful and pretty. It has been a major challenge to release products as the unexpected resource constraints have continued from the issues we had in 2015. It’s led me be a more hands-on leader and working more in the trenches rather than leading via mockups, whiteboards, and design sessions like was sold to me out of the gate. While it’s a daily struggle to contain my aspirations for the growth of the company I do take pride in the skill growth of my technical and product teams.

Getting involved. I worked hard in 2016 to expand my presence in the Minneapolis tech community; I find these events a challenge because I’m always prone to work extra or unplug rather than attend events but I’ve been continuing my effort from 2015 to meet up with past colleagues and friends at local events like: minnedemo, minneanalytics, startup week, and conferences on AWS and IoT. In addition I started volunteering at our local coderDojo which offers a great way to give back and inspired me to make the time to teach in more rigorous fashion. In the fall, I started as an adjunct in the computer science department at my alma mater the University of Minnesota. It’s a great university and the opportunity to interact with the next generation of engineers and give a little back to the community has been wonderful. I’m teaching a Senior Design course over two semesters where industry sponsors a class and we are given resources to build something interesting. My groups sponsor is Microsoft and they’ve been great to work with.

Travel. Working is overrated and Kelly and I focus on taking time off and exploring so we stay fresh. 2015 brought another trip to Spain for us where we hit Madrid, Seville, Granada, and Barcelona. Two separate trips to Lake Superior’s north shore.  Two buddy ski trips to Colorado and the purchase of an Epic pass for the 2016-17 season. For my birthday we hit up Palm Springs and rock climbed in Joshua Tree National Park. A weekend in Kansas City. A Colorado summer road trip with our pooch. And an epic guy’s climbing trip in the Grand Tetons. Another Lake Superior weekend but over in Bayfield. And we ended the year with a trip to Santa Fe.

Weightlifting. I continue to focus on active and healthy living through a love of practicing sports. Through the years they’ve migrated from team sports like rugby and softball to individual pursuits like marathoning and now olympic weightlifting which I’ve been doing for 3 years. In 2016 I switched my training location to Crossfit Kingfield where I’ve met great people and coaches. I compete as a master’s lifter (graybeard) and focus on getting stronger while considering the long game and adapting to the gifts of aging. I had a 4-5 month wrist issue that led to me missing my 2016 goals but I still had fun and improved my consistency. I train 3-4 days a week and try to compete at a few meets a year and through that I qualified for the master worlds championships at the end of April in New Zealand…I’m going!

My best lifts of the year were:

  • Snatch – 116 KG
  • Clean and Jerk – 145 KG
  • Back Squat – 196 KG for 3 sets of 3

The snatch and clean and jerk weren’t up to my goals but with health they’ll be bested in 2017 as I enter a new age class.

Reading. I’m always reading and we resubscribed to the New Yorker and other magazines so the book reading took a hit but I still managed 15 books in 2016 and I’ve been reading the Stephen King Dark Tower books which are thick ones so I get a bump there. Besides product management and tech books I read a lot of books focused on racial topics.

Highlights:

2. What didn’t go so well this year?

Writing. I’ve given up the goal of more technical and product writing as it’s been a continued goal I’ve missed for years but another goal I had was to start writing short stories and hoping that would lead to something interesting in either the hobbyist’s pursuit or for the book idea I’ve been noodling on. I’m going to continue that goal and work on journaling and take the computer out of the equation in the hope that the act of writing via the pen will appeal to my creative side a bit more.

Open Source contributing. My open source contribution back to the tech community is best summed via ‘blah’. I count this as a curse of my years consulting when I could either give back or do work that allowed me to bill more hours. I always took the billable time which may have been symbiotically tied to my taste for vacations! Anyway, I didn’t do much in 2016. For 2017, I can contribute via my students project as an advisor and also have my eye on a Alexa/Sonos integration via NodeJS and data science work via python.

Company Growth. Much of this is out of my control but the growth issues at SetSight affect me and are affected by me as the tech leader. While I don’t see the team(s) size reaching the levels I planned for us to hit in 2015 I need to continue to put my best foot forward to lead and deliver results with the truth of where we are at as we approach 2017. It can be easy to get caught up in how the expectations didn’t match the outcome but outside of honest reflection used on the road to improvement it doesn’t do much good.

3. What am I working toward?

Looking back, 2016 felt like a float year somewhat. I wasn’t working at the scale where I can put my talents to maximal use so it felt a bit underwhelming and simplistic. However, there were  some nice wins in there through work successes, adjunct teaching, and focus on work-life balance. 2017 can get better by delivering the growth we can hit rather than getting bogged down by the growth we lost out on that were outside of our control. For 2017 I plan to focus on.

Doing less and doing that better. I’m a classic overachiever and when I get time I always sign up for more stuff to do. That’s why I have two graduate degrees and since my MBA have started volunteering and teaching. I need not add anything else and instead create the free-time where I can explore technology, product ideas, and create. That idle time is where the sticky ideas come from, I need to make that idle time.

Simple and healthy. 2016 found me focused on diet, sleep, and health. I want to continue that in 2017 by averaging 7.5+ hours of sleep for the year, hitting the sauna 5 days a week and practicing yoga 3 days a week. The more I work and the more I spend at the keyboard the less I can offer as the creative idea person that I think brings the most value to others. Balance is key and I need to remember my saying that I’m a sprinter and not a long-distance running. Sprinters require plenty of rest, stretching, and focus.

2017 – ready or not.

What’s a Consistent User Experience?

In tech, we have all mostly moved on from the days of projects based work and now speak in the language of software products. We have our product lines, product road maps, product backlogs, and planned product features. If you’re in that type of environment you likely leverage personas or user stories to describe your type of users which you then bring in when planning the user experience…which like many areas is the “most important thing”. You may have different goals for your particular user experience but certainly we can assume that you’d like the experience to be consistent and straight-forward.

We are a smaller company and yet we still have 4 core products and one could argue we have many more with the legacy applications features we still support. Its been a tough few years which brought with it resource constraints so we have to often revisit the backlogs and re-prioritize. Because of those constraints we made a strategic decision to not roll our own presentation on our large data sets. This decision was initially made to offer a new product line that would be help a smaller but promising pool of retail suppliers and reps that didn’t need all the features of our flagship. So we partnered with Tableau in order to bring their BI features to help make our retail data analysis pop.

The new product line is progressing but the real change has been the internal emphasis of leveraging Tableau in other products. This one will be a technical dozy for us since we developed a new API with our flagship with the thought that the front-end would be handled by our team via D3 or something similar. Technical issues arise, we’ll handle that.

So what’s a consistent User Experience?

As we’ve moved our systems to AWS and ported many of our stacks away from Windows and into distributed architectures we’ve seen great gains. We’ve also moved from SQL Server to AWS Aurora / MySQL to have both ease of administration as well as a cost savings. With a recent new Tableau deployment a member on my BI team ran into an issue which goes against an ideal user experience. From what I’ve pieced together when Tableau Desktop (a client) is installed it adds all the prerequisites apps and drivers to support MySQL out of the box but when you install Server it does not do this but does install Postgres which it uses internally.

This leads to an user experience where someone can connect to MySQL on their client, make the snazziest dashboard experience known to humankind but when they publish success is not had because MySQL drivers are not present. So on the client side the install does something and on the server side it doesn’t do that same thing?

That to me is a good example of on an inconsistent user experience. Perhaps there is a good reason for it, perhaps there is documentation and instructions to detail it, or a road map item to correct the inconsistency on the backlog. In the meantime, users are going “huh”.

Gist Series – Methodologies: Agile, Scrum, and Waterfall

The Gist series came about from a Senior Design course I’m teaching as an adjunct at the University of Minnesota’s Computer Science department for the 2016-2017 academic year. The focus on that course is to have the team of students design and build a software project while partnering with an industry partner, in our case Microsoft. Just like in my day job, I’m there to assist them through technical and product evolution through leadership and it also offers me a chance to give back to my alma mater. One of the areas where I’m trying to do that is with a ‘real world’ lesson. I plan to take a topic and present a concise take on it. Thus far they’ve been in the top-down academic paradigm which tend to over-formalize processes that they’ll see soon as software engineers. My aim is to help them see that all the theory gets molded and formed for the environment it lives in as well as to respond to fast moving topics that move too quickly for typical curriculum.
Because we are going to use Scrum as our process it seemed the ideal first topic.

What is Agile about?

This deals with the development methodologies. The traditional is waterfall which is a sequential top-down process. And you go down, you don’t go back up…just like a waterfall. Waterfall has been around forever and it does work. Some of the best examples (and worst too) have been with defense software projects. The keys to having success is to be really solid in requirements gathering and being able to effectively lock in the design. However, waterfall often failed leading to really bad anecdotes about development but really good books like the Mythical Man Month. The main reasons it would fail is that requirements typically change. Either the stakeholders want something else because of something unknown or because now that they see it working it matches what they said but not what they meant; often its too late to effectively veer so changes are expensive, deployments don’t always feel like a victory, and folks may be left grumpy. Plus a project can be years long and not all resources are effectively leveraged. I remember a project I was asked to work on for a bank conversion where requirements was going to take 6 months and I asked what the 70 person team of developers would be doing in that time and I was told I would develop a training program for them until the requirements where done. Whoa…outside the scope of normal but true story.

So What is Agile.

To me, Agile is an adaptive, iterative methodology that focus on getting feedback quickly (fail fast for the startup school folks out there) and prioritizes communication over the upfront complete requirements gathering of waterfall. You do this by focusing on smaller chunks of work, typically 2 or 4 week sprints, and can effectively veer based on outcomes that show themselves. These are my words, google can help you find exactness. With agile, specifically scrum, the team is more of a team. The product owner is consistently communicating with the developers so days/weeks aren’t going by with lingering questions or unknowns being left unanswered. Buy in with the team is much higher in my experience because the team should be heavily leveraged in sprint planning by determining cost/risk as well as priority of features to the project. Additionally, communication is key and daily standup’s help foster that team communication. Because the team in constantly checking in with what they’ve done, plan to do, and what they’re hung up on problems are resolved much faster and that brings faster delivery of features. This can be measured with velocity.

Why Does this Matter

This matters because you’re going to work in one or the other process or a mashup of the two or a frakenscrumfall. Either way, in the least its good to know what to expect if you’re ambivalent. Secondly, if you care, then you can look for a workplace that employs the process you most align with. Most newbies think the key to their job satisfaction is the tech stack, the perks, and/or the pay. I tend to find that job satisfactions comes down to your boss and the way the team interacts, oh, and if you have Nerf wars! I miss that job. Lastly, if you don’t have an opinion I really don’t want to work with you. Do you know how boring it is to ask intelligent engineers what they think about something and then hear crickets?

Some Other Common Questions

So what sucks about scrum?

People generally make anything that sucks suck. Agile has very specific roles and responsibilities and they are crucial to success. The biggest is the scrum master who is like the project manager in a waterfall scenario. The scrum master has to keep the sprint running smoothly by facilitating the communication between the product owner and the developers that we’ve mentioned is key. They also have a fair bit of administrative work in tracking the sprints versus the overall project. For this role I really like detail-oriented folks who like organizing folks, in my experience a kick-ass project manager will be a kick-ass scrum master.
The product owner is also a key role as they must have their act together with the stories. The stories are the requirements so they need to write them with that in mind, or have some help from a BA type of person. The dev team also has to learn to be involved and to try to get away from the ambivalent tech gloom vibe that some team members can bring. After a few months they’ll hopefully learn from the rest of the team or figure out they don’t like process enough to find a new home.
What generally doesn’t work but is often attempted at smaller shops is to part-time these roles. If you’re moving to scrum then have the person filling the key roles have a majority of there time spent working in that role. I’ve had scrum masters that only kickoff the stand-ups and don’t do anything else. #thanks #facepalm #supposeyouwantaraise

How do we build something large though?

Scrum can totally be used, Google search can again back me up here. I’m not really covering Scrum per se, just hitting it quick. Stories live on the product backlog and larger stories are called epics. Epics can be contained on a product road map which shows the major features and phases of a specific products. So you can plan out our product for years. That’s part of what I do and I have a road map for each of our major products as well as our tech infrastructure which feeds into the backlog where specific product owners go and add their magic before it goes into the sprint and then gets D-O-N-E.

What tools do you use?

I have a strong view on tools in that they really don’t matter as much as being consistent with whatever tool you have. That being said, from my statements above I must be opinionated, and I am, so I lean towards tools that follow Occam’s razor. I’ve had folks that like to write stories in Drive docs and then copy them to the scrum tool of the moment. If that works for them then awesome sauce but I just prefer to write the story once, in the place where it will be consumed. I prefer to use Trello over Jira because its simpler. For road maps I prefer Drive sheets over SaaS based road map tooling but in the end whatever the team wants is fine by me.

What if someone doesn’t like it?

There are always engineers who don’t like change or can nitpick a methodology to death. You know what, odds are if you do waterfall they will have the same view. Additionally, I’m willing to wager that if you offer this fictional representation of a developer the chance to develop the best methodology that they will pass because they don’t actually care. What’s great about scrum is you can make it light and flexible or as big and heavy as you see fit.

I’m really a kick ass coder and I want to be left alone

I feel you! I used to think like that then I learned I liked sunshine, people, and puppies. Seriously though, this stuff is everywhere so if you have a tough time working with folks you should maybe be a professional widget maker at home or get a gig with fsociety.

Where’s your pictures showing the methodologies that I see in all the good posts?

Who said good post? Anyway, they are only a click away.Here you go!

Teaching Tip: It’s what to do right, not what to do wrong.

Today while driving I was listening to the Barbell Shrugged podcast, it’s been around a few years and while it generally focuses on CrossFit I listen for the episodes when they hit topics like Olympic weightlifting, coaching, or self-improvement. Like this one!

Doug Larson, a Barbell Shrugged OG, raised a point I liked in how he teaches people…on anything. Doug focuses on what they should do, not on what they shouldn’t do. It’s a subtle point to consider and instantly brought me to design sessions I may have with engineers and architects at work where I catch myself often telling what NOT to do. It’s really a poor tactic of persuasion and teaching as it doesn’t focus on what they should do.

Thanks Doug!

Domain Driven Design – 10 Years Later

I’ve been an avid podcaster since its inception and before podcasting I would web stream my favorite radio shows like This American Life or download the files and transfer them to crappy MP3 flash player. Ah the memories of the days before the iPhone.

I finally caught up with a software engineering radio pod from May of 2015 where the topic was reflecting on Eric Evan’s classic text Domain Driven Design 10 years after its publication.  Reflecting is right. When that book came out I about to start grad school at the University of Minnesota and reading every decent text I could get my hands on. I’ve always prefered looking wide and long at the software field and was drawn to software design, product design, & user experience rather than focusing on stack specialization, russian algorithms, etc. so Eric’s book was a natural fit for me and I remember loving it and praising to all my peers.

Those were critical years in my engineering & leadership development, I was two years removed from creating a flexible ecommerce platform with my mentor and was just beginning with a few new firms around e-leasing & digital media ecommerce.

The software engineering pod brought Eric’s voice back into my head and the terms and language from the book flushed into my thoughts. It’s amazing how memory recall can be effortless when the material, even if distant, struck a chord and anchored in your thought process.

This pod covered how DDD relates to the terms of today like: CQRS, NoSQL, & event sourcing. I was struck with how the principles of DDD have been reflected in the designs of the companies, teams, and projects I’ve worked with since 2005, regardless of the tech space or stack.  I think the book provides considerations that are still very valid today. If you haven’t read the book it’s worth your time, if you have read the book then check out the pod.

Eberhard Wolff talks with Eric Evans, the founder of domain-driven design (DDD), about its impact after 10 years. DDD consists of domain-modelling patterns; it has established itself as a sound approach for designing systems with complex requirements. The show covers an introduction to DDD, how the community’s understanding of DDD has changed in the last 10 years, the often overlooked component—strategic design, how to use DDD to design microservices, and the connection between microservices and the DDD bounded context. DDD originated during the era of object orientation and relational databases; the show concludes with a look at the recent impact of functional programming and NoSQL on DDD.