Categories
All Consulting CTO/CIO

How do we make domain decisions when coding software?

via GIPHY

I stumbled on an interesting discussion over at hacker news about when you have to make a decision in code outside of your domain of expertise.

This is a super interesting topic to me. As the world is more and more powered by computers and algorithms, this seemingly obscure philisophical corner of computing begins to affect us all.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

While many programmers are familiar with the experience of stumbling upon an edge case which wasn’t covered in the spec. The truth is you can’t go back and block on every single tiny detail.

Some of the bigger ones can trigger further discussion, but were it not for Falsehoods programmers believe about X the software would never go out the door.

Here’s some more food for thought…

1. Falsehoods programmers believe about names

o They won’t be a *bad* word. Whose bad? i’m not sure.
o All people have names.
o We only have to work with names from English.
o Names are ordered in a sensible manner.
o A name won’t have to change later.

You get the picture. As you start working with the minutae around names, you realize there is a lot of assumptions. Even when you weed out the big ones, there are still small assumptions.

Ultimately, you can’t get to the bottom. There will always be some assumptions, and as software evolves, changes will be required to match the real world. Living systems grow. Software systems must receive *updates*.

Read: What happened when I offered advice outside my pay grade?

2. Falsehoods programmers believe about selling products

o each product has a price
o each product has one price
o each product is one unit
o two decimal places is enough for all currencies
o all currencies have a unicode symbol

There are many more. The point is once you start digging, everything gets fuzzy. Products can be in stock and not in the warehouse. Single product can have multiple prices. It goes on and on!

Read: What did Matt Ranney discover scaling Uber to 1000 microservices?

3. Falsehoods programmers believe about addresses

o two districts will not have the same number
o postal codes will agree across jurisdictions
o a fixed number of characters will work for every address
o roads have names
o buildings are not numbered zero

Addresses are *really* messy. I remember being surprised when I moved to brooklyn. Streeteasy & Google put me in different neighborhoods. I asked my lawyer why this was. He said DOB and the post office use different databases. And google further samples from one or the other.

Never the twain shall meet!

Related: Can humility help you in your career?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
Uncategorized

How do you hire the best talent in a competitive marketplace?

via GIPHY

Kapwing, a scrappy startup out of SF wrote this excellent piece how they hired 10 employees in the very tight bay area market. It caught my attention because the demand for great people has never been higher.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

Here are the ways they found great people…

1. Events

Meetups are always an excellent way to find great people. Tech networking, can be one part selling your ideas, projecting your prowess or career building for your own people. And meanwhile career forward, self-actuated employees are scoping you out too.

Check out: What did Matt Ranney discover scaling Uber to 1000 microservices?

2. Friend referrals

Connecting through your own people is always a good way to find talent. These referrals are also great because you already have a handle on the hires real-world experience and personality. Good for everybody.

Also: What happened when I offered advice outside my pay grade?

3. Press

As your startup grows, you get some press in TechCrunch or ReCode. This generates some household recognition in the tech community, or posts on HackerNews. From there you get inbound requests because smart people are on the prowl for a great company. Done & done!

Related: Can humility help you in your career?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All Consulting CTO/CIO Devops

What do senior engineers do differently?

via GIPHY

I recently stumbled up on this piece at Pivotal, The art of interrupting software engineers. It caught my attention because i like to read from a different vantage from my own.

What is it like to interrupt us?

Join 35,000 others and follow Sean Hull on twitter @hullsean.

What I really got from the article though, was how different types of engineers will think about problems differently.

1. Under the hood

For junior engineers who are still a bit green, and new to working in industry, they’re downward facing. Focusing solely under the hood, they may not see how their work contributes to a product, or how it fits into the overall picture for the business.

“When asked about their progress on a story, they would make an effort to ensure I understood what was happening under the hood and what tradeoffs they were facing using a vocabulary I was familiar with. ”

For her it was technical competence that stood out – or at least not the only thing – but rather how they were strategizing, and communicating their problems, challenges, and progress.

Read: What happened when I offered advice outside my pay grade?

2. Communicate discoveries

A more intermediate engineer, would sometimes anticipate & communicate better.

“In some cases, those engineers would come to me before I even had a chance to enter the paranoid zone and give me a simple explanation of how the team had learned new information since they first estimated the complexity of a story. ”

She is also speaking of situational awareness. So not working in a vacuum, communicating & incorporating that new information as it becomes available.

Read: What did Matt Ranney discover scaling Uber to 1000 microservices?

3. Anticipate in advance

Senior engineers, she says would really stay ahead of the curve. They were even anticipating what might be a roadblock for her product delivery.


“Some of the very best practitioners would ask me in advance how urgently we should deliver a particular user story and what we were ready to give up in order to ship faster.”

Weighing tradeoffs, and prioritizing is a huge factor in velocity. If you can tame that beast, you’ll go very far indeed!

Related: Can humility help you in your career?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters