Tag Archives: Programming

Johnny Boursiquot on building a software agency from scratch, learning Go for Rubyists, and server-less software architectures.

Listen to this episode of Hacker Practice on iTunes today.

Sometimes you start a conversation with one intention, and digress into something completely different.

This happened to me recently, in a conversation with an old friend and mentor, Johnny Boursiquot.

Johnny and I were supposed to do a deep dive into Go Lang and Ruby in this hour long conversation. Instead we spent half an hour talking about Johnny’s experience building a technology agency from scratch.

Then we got around to talking tech XD.

Johnny is well-known as one of the pillars of BostonRB. He also helped to organize the Boston GoLang meetup before moving to Maryland where he founded Baltimore’s GoLang Meetup.

He was listed on New Relic’s list of 18 Go Experts to Follow Online.

In the episode we talk about:

  • Johnny’s lessons learned from founding and building a tech agency, lots of juicy business advice for consulting companies and agencies in the first half of this talk
  • The relative pros and cons of using ruby vs go in different domains
  • How to get started using a new language

  • A quick primer in serverless application architectures

  • How intermediate devs can 10x their workflow

And a lot more.

Enjoy.

Notes

[00:00] What brings Johnny to Maryland after living more than a decade in Boston

  • What brought him to Boston in the first place

[02:30] Major lessons learned from time in Boston running a technology company

  • Running a company means that you’re responsible for other people’s income
  • Many unexpected challenges: biz dev, legal, etc

[05:15] How did Johnny get started in technology business.

  • Started with entrepreneurship in high school

[08:00] Learning how to do business

  • Dealing with clients
  • Managing expectation
  • Touching on the difference between hacking and building a product

[11:00] #1 Lesson? The difference between a service business and product business

  • Agencies do not scale the same way a product scales
  • Most agencies do not end up producing a lot of reusable technology or internal products
  • It’s hard to do internal product development because your staff is busy with revenue generating service activities
  • It’s risky to invest in product development

[20:00] What would Johnny do differently if he could start over?

  • Start a product company: raise money.

[23:00] What about the reverse situation? Making a profitable, successful agency.

  • Protect your margins
  • Be flexible with workflow; Agile doesn’t always work smoothly in an agency environment
  • “They want warez”
  • Your job is to tease out the specifics of what the client actually wants
  • “You’re not in control of your own product roadmap”

[27:30] How to mitigate risk of scope creep

  • Establish a relationship; a partnership to guarantee future work
  • Get a Master Services Agreement

[32:00] Segue to technical discussion. What is Ruby good for vs Golang?

  • Ruby for developing something fast. “Getting a web app out there as fast as possible”
  • GoLang is better for heavy lifting, whenever performance is a consideration

[37:45] What are Johnny’s tips for learning Go (or any language)

  • “Leave baggage at the door…appreciate the differences of Go”
  • There is a “Go Way” of doing things

[41:15] What kind of project should I try using GO in

  • Anything with heavy duty network requirements
  • Microservices (“Something you can throw away”)
  • “Gnarly, performance-critical jobs”
  • Concurrency in Go is super-awesome

[45:00] AWS Lambda and Serverless 101

  • Not actually “serverless”. That’s a marketing term. There is always a server somewhere.
  • Monolithic App > Microservices > Lambda functions
  • Everything is a discrete functional unit
  • Very cost-effective because the server only runs when you call the function

[51:30] What can an intermediate Rails developer to 10-20x their workflow

  • Look past the magic of the language (Ruby) or framework (Rails)
  • Learn the underlying properties of the WYSIWYG
  • Understand how SQL, HTTP, Databases, and CURL — fundamentals of the web — work
  • Learning the underlying complexity enables you to use the higher-level abstractions more rapidly

[59:00] Johnny’s relationship with the command line

  • Used to work in Windows, and mostly everything was a GUI
  • Put together command-line tools to build Flash experiences
  • Started using Ubuntu – understood that there are discrete tools to use and stitch together from the command line
  • Now uses a Mac. Everything can be done from the terminal

[1:05:45] Running swift on the server

[1:07:00] Johnny’s new life hack

  • Modified Pomodoro with a physical twist

[1:10:00] Johnny’s child-rearing hacks

    • Every child is different
    • Reward effort over innate qualities
    • Lots of people squander innate talent. Working hard never fails.

[1:14:00] Johnny’s new job at an education non-profit

  • Serving under-served school districts
  • Exposing diverse groups to the world of technology
  • Bring education equity to the communities that need it most
  • Mostly doing ops work these days
  • The biggest challenge is always dealing with people
  • Johnny loves pairing with more junior members

[1:20:00] Final requests to the audience and where to find Johnny

What now?

Go become a better programmer. And subscribe to the show on iTunes.

Pareto Programming (How to be an 80/20 Coder)

Image

First of all, let’s define Pareto’s principle for the uninitiated:

80% of the output stems from 20% of the input.

Get it? 20% of labor produces 80% of value. 20% of your clients contribute 80% of your revenue. 20% of your code does 80% of the work.

Read Tim Ferriss’s material to learn more about using Pareto’s Principle to change your life outside of coding.

If you’re a coder, we’ll want to use this idea to our advantage. The first thing that comes to mind is testing. I make a proposition:

80% of your coverage comes from 20% of your tests. Ask yourself: What are the 20% of tests that will accomplish 80% of the coverage? Whatever the answer is are the tests you should write first.

This thinking can also be applied to UX design. What are 20% of features that will provide 80% of the value to my users? Those are the features that you spec out first.

Let me give you a great example of this: Last week, at Launch Academy‘s Ship It Saturday hackathon, my friend Peter and I built a small photo-blog called #BostonsBad. The concept is simple: A user-generated content site that provides a simple and intuitive interface for submitting and curating images.

Immediately, a number of features come to mind:

  • Social/sharing mechanism
  • User log-in
  • User profiles
  • Content submission
  • Admin/Curation interface
  • “Follow” for notifications
  • Follow individual submitters
  • Comments
  • User-facing homepage
  • etc etc…

So, in the midst of the muck of the brainstorm, it’s easy to see how this project could grow out of control and never be deployed. As an experience UX designer, it’s imperative for me identify the most important features to develop and get this thing on the web. These features are the 20% that will comprise 80% of the value. 

For us, these features were clear:

We needed:

– A user-facing homepage

– A content submission mechanism

– and an easy-to-use content curation interface.

Not in that order. Obviously, the front-end is contingent on a functioning back-end in this case.

We built out a slick submission engine using Instagram. Users don’t need to download an app or even visit the site to submit content. All they need to do is Instagram a photo using the hashtag #BostonsBad. We scrape their API for these photos and add them to our database as they’re submitted.

That’s a simple user experience.

On our end, those photos get emailed to the site’s administrator (me) for acceptance. I DON’T EVEN NEED TO VISIT THE SITE. This is huge for me. I don’t want to have to wait by my computer to manage incoming content. I want to be able to look at it, and give it a yes or no on the spot.

After that, building the front-end was cake. We deployed to heroku and I bought the domain name and you can check out the working prototype here.

The important thing to remember here, is that we took a big idea and pared it down to the significant 20% that would allow people to use the product. 

What about you? What are some times you’ve been able to make small changes for a big impact?