Shaun Martin, Director of Software Development

What Google Taught Me About Scaling Engineering Teams by Edmond Lau
Even though our Product and Engineering orgs are currently in a slower, steady growth phase, there are always ways to improve communication, knowledge sharing and team/department structure at various stages.
For the New Team Lead: The First Six Things You Should Know
We’re entrenched in formalizing leadership training for all our Development Team Leads for the first time, previously relying (quite effectively) on a one-on-one mentorship approach. This post was shared by one of our Team Leads, and it highlights a lot of soft skills and challenges facing new leaders.

You Are Not Paid to Write Code

A thought- and discussion-provoking post from Brave New Geek, this post addresses the tunnel vision we often succumb to as developers, believing our problem space to be 100% unique. Developers are paid to solve problems with as few lines of code as possible, keeping solutions elegant yet simple. To do this, we need to take the time to research and leverage existing frameworks, libraries, open source projects and other solutions that get us 90% of the way there. Instead of “reinventing the wheel”, developers have a tendency to build our special snowflake sedan by reinventing the axles, glovebox, steering column and A/C.
The Obstacle is the Way by Ryan Holiday (book)
The third book from Ryan Holiday, its title was inspired by an entry in Marcus Aurelius’ Meditations: “The impediment to action advances action. What stands in the way becomes the way.” Problems are inevitable, so when you view each challenge as an opportunity to learn and a chance to practice one or more virtues, your entire perspective on your problems begins to change.

Bill Fienberg, Developer

The Willpower Instinct: How Self-Control Works, Why It Matters, and What You Can Do to Get More of It by Kelly McGonigal (book)
Laughing at myself because it’s taken me months to finish a book that is supposed to help you increase your willpower.

Brent Lewis, Developer

Software Estimation: Demystifying the Black Art by Steve McConnell (book)

Evan Machnic, DevOps Engineer

The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford (book)
This is a nice quick read  about a fictional company that adopts DevOps practices to bring projects under control and save the business. Great read for anyone who works in technology, not just for DevOps.
The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, and John Willis (book)
This is a companion book to The Phoenix Project. It builds on the principles in Phoenix and outlines how to put those principles into practice in the real world. If you’re looking to implement DevOps in your company or you want to really understand the Three Ways of DevOps, this is a great read.

[amp-cta id=’8486′]

The post What We’re Reading Between Pushes, Vol. 2 appeared first on The uShip Blog.

Jacob Calder, Developer (Payments)

Why Uber Switched to MySQL from PostGres
A technical explanation of why Uber switched including discussions of the architectures of both databases. Postgres has responded to this here and here.
A Look at How Postgres Executes a Tiny Join
A technical explanation of what actually happens when you perform a join in postgres. A great way to start moving beyond understanding how to use a database and to start building an understanding of how they work.

Brent Lewis, Developer (Platform, Front-End specialization)

React: Mixins Considered Harmful
An early example of a potential anti-pattern in React. If you heed the warning, it would be an insightful way to ensure new React code is maintainable.
How Becoming a Pilot Made Me a Better Programmer
When critical issues appear mid-flight, being able to both read and cross-check instrumentation will save your life – valuable lessons for web development production systems.

Zack Whipkey, Developer (Platform, Back-End specialization)

Influence: Science and Practice
If you’re working with vendors for third party tools, it’s good to identify whenever someone is attempting to sell you something without sound reasoning.
Jeff Atwood – They Have to Be Monsters
A deep look into a ugliness of communication on the internet, especially public facing. If you ever write a blog, or get into public speaking in cyberspace, best to be prepared.

Matt Hayes, Sr. Developer (iOS)

Idea Flow
When development best practices fail, what can you do?  See how one team used detailed metrics and reporting to solve the problems that fell through the cracks.
iWoz : Computer Geek to Cult Icon
The story of Steve Wozniak’s career, in his own words.  From building his first computer to the Apple I to inventing the universal remote control, this gives an interesting perspective on the early days in Silicon Valley and one pretty darn influential hardware engineer.

Shaun Martin, Director of Development

How To Empower Your Employees To Act Like Entrepreneurs
I’m a big fan of the Lean Startup principles and practices, and as uShip grows I want to make sure we maintain the ability to move quickly, take calculated risks and continue on the path to disrupt an outdated industry.
Ego is the Enemy (book)
This is the best book I’ve read in years. Ryan Holiday is a former assistant to Robert Greene (48 Laws of Power, 33 Strategies of War) and a student of stoicism. In his fourth book, he shares historical and personal examples of how allowing your sense of self-importance can cripple the execution of your purpose and mission. Examples include Napolean, Ghengis Khan, Steve Jobs, Bill Belichick, Dov Charney and John Delorean among many others.
The Pragmatic Programmer Quick Reference Guide
Not so much “reading” as it is “constantly referencing”. I refer to a handful of items from this list every week to do a health check on our teams and ensure they’re constantly striving to improve.

The post What We’re Reading appeared first on The uShip Blog.

Below are some of the takeaways from our team of 40 developers who have participated in a dozen or so hackathons to this point.

Preparation is key | Hackathons

Throwing together a hackathon at the last minute can work, but only if you have folks who already have ideas queued up and ready to execute. Otherwise, you’re looking at a complete crapshoot. If you’re going to want people to spend part of a weekend at work, no matter the reason, you’d better give them notice.

This is where building a hack-centric culture is invaluable, as it becomes something people want to do naturally (more on that later). Try to create a buzz about the event organically. Use the weeks leading up to the event to build anticipation. Getting developers excited about the hackathon can be trying at times, but it’s extremely important.

Involve non-technical staff, when possible | Hackathons

We now hold Engineering Department hackathons once or twice per quarter. At least once a year, however, we have a company-wide hackathon as one of our monthly “First Friday” events. During the larger events, Developers learn about pain points in user experience from our sales, business development, and customer operations teams.

Encourage your non-technical staff to submit projects, recruit a team, act as a QA and SME, or even get their hands dirty in development. Help them cultivate their idea from a problem-solving approach rather than a solutions-first one. An example might be, “I can’t search for a shipment by location,” vs. “Build a new shipment reporting screen”.

This way, your entire staff gets exposure to an outside-the-box line of thinking. By opening things up to members outside the dev team, we’ve discovered employees who were interested in development then later went through our internship program and eventually became full-time developers.

Facilitating connections is more important than organizing | Hackathons

If you’re the organizer or part of an organizing committee, you don’t need to manage this event. Put people in the best position to learn about proposed projects, and they will naturally self organize. For internal events, you don’t need to overthink structure nor apply a theme.

At the event, the location where folks do the hacking is much more important than it may seem. Are people sequestered in far away rooms? If so, they might be more productive, but it can feel like work. We prefer getting as many people together as possible in a big room, with plentiful beverages and some music.

Timing can be challenging | Hackathons

Avoid scheduling hackathons on days where people tend to be out, like holidays or popular festivals. Low participation can kill the morale of those who attend. It’s also pretty uncommon that somebody wants to work a full week and then spend an additional day or two at the office,even if it’s on a project of their choosing. Cutting into normal work hours will probably not affect sprint commitments that much, but it will prove to developers that management truly believes in the value of hackathons.
Multiple days > 24 hours
To expand on the last point, the best hackathon projects we’ve produced have come from multi-day hackathons. Recently, we reserved the 3 days before Thanksgiving and gave our Engineering team that time to work on whatever their hearts desired. Typically, a high percentage of the team would take one or more days of PTO that week to get an early start on holiday travel anyway, so those who remained were able to plan and execute over multiple days on projects with a significant scope. Given that amount of time, people were able to give their projects more polish and solve some of the nagging issues that we typically ignore during a more rushed timeframe.

Follow through | Hackathons

A hackathon isn’t just a weekend event. Once the novelty wears off (after one or two events), developers may justifiably begin to question why they should continue to participate if nothing is done with any of the projects. Generally speaking, the purpose of a hackathon is to quickly produce a piece or proof of concept of a potentially big idea. If people don’t believe the leadership will champion the most promising ideas across the company, they’ll stop building them and, god forbid, become less inclined to generate big ideas altogether.

We’ve pushed for buy-in from technical and product leadership to see that, where applicable, pieces or sometimes entire hackathon projects are put into the development pipeline. The code gets cleaned up/re-architected, sent through QA and integrated into the platform. From the image upload in our mobile apps to an improved cancellation experience, we’ve had multiple projects see their way to production.

Also, ending the event in a formal way is important — we make it a point to reserve the following week’s Engineering Team Meeting for presentations so that people have a chance to show off their work. While creating something that nobody sees can still be a valuable exercise or learning experience, recognition from your coworkers can make the whole thing feel worth it.

[BONUS] Quick tips:

It’s pricey, but people love quality catered food. East Side Pies pizza and Gus’ Fried Chicken (local favorites) have been much appreciated by attendees. They also love prizes and fun t-shirts. You don’t have to do this for smaller, impromptu hackathons, but the big “official” ones greatly benefit from more ceremony.
One of the best things we ever did for hackathons was to create a custom trophy for the crowd-voted winner. It’s a semi-realistic looking stuffed bear mounted on a giant base with a custom plaque. Did I mention it has chainsaws for hands and its eyes flicker red when a switch is turned on? Words can’t do him justice. The winning team shares custody, so this magnificent thing goes on a victory tour through the office.
Play the movie Hackers in the background somewhere, at least once. (Warning: movie contains nudity)
People have obligations that require them to leave — family and pets are important, too. Encourage people to come and go as they need to. It’s better than them not attending at all.

(Thanks to Brent Lewis for his contributions to this post)

The post 6 Major Lessons from uShip Hackathons appeared first on The uShip Blog.