• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Dion Almaer

Software, Development, Products

  • @dalmaer
  • LinkedIn
  • Medium
  • RSS
  • Show Search
Hide Search

Archives for September 2014

Haters Gunna Hate; Why do we denigrate certain technologies and people who use them?

September 16, 2014 Leave a Comment

The Playa Haters as seen on Dave Chappelle’s Show

“Don’t hate the player, hate the game” — Ice T

Why do we often love to hate (especially with schadenfreude when something goes wrong)?

I see this time and time again, but often in the world of technology. Engineers make value judgements quickly based on what technology is being used.

God forbid you are building your latest Web site in PHP. Giggling at the people who wrote .NET. Rails? Scales? Visual Basic!

And then you get to the micro level. Did you use jQuery or Prototype? Backbone or Ember?

We love to make value judgements based on some tiny pieces of information. I mean, it is just so much easier to have that level of abstraction versus having to actually understand the context!

It feels great to build a class system and look down on the lower classes.

I have to admit, I have to fight impulses at times. I jump to conclusions. The thing is, why do we have to hate so much?

It isn’t that you shouldn’t care about what tools you are using. As much as I feel like we should care most about how we are affecting the lives of people via our products, that doesn’t mean that the tools don’t matter.

The tools are important as they:

#1 The right tools get the highest quality experience to the customer as fast as possible

#2 The right tools can feel right to you, which enables #1.

Ruby felt right with my brain. I enjoy other languages, but Ruby felt right in a way that Java (and other languages and platforms) never did. Since I can acknowledge that for myself, can I see the potential that others may connect with other choices that feel right to them?

I find it particularly interesting when people argue about back end technology. Truly, who cares what is spitting out the HTML for that web page.

When it gets to be closer to the experience I can see more reason to bemoan. If you recognize that hybrid tech that truly sucks…. I get it. That Swing app that is pausing all the time for GC. This is affecting you as a user in very real terms.

TDD is dead

Another good example recently was the big kerfuffle when DHH got folks up in arms over a debate on the merits of TDD.

It is fine to spark a conversation by pushing the boundaries. This can be a good firestarter, but whenever we get to absolutes and mix up “I don’t think this makes sense at all for my needs” with “no one should ever want to do this and I don’t think there is any value in this at all” I get concerned. There are some extremes where we come together as a society (You can’t murder someone randomly), but the level of arguments that we get into over petty things is just that… petty.

Music to my ears

I relate this to music. I am not a huge fan of certain genres such as rap, punk, or heavy metal. Does this mean I should:

  • Think those genres are lower?
  • Can’t appreciate that others may enjoy them (given the data that shows that they DO ENJOY THEM)?
  • Need to go out of my way to find those people and tell them they suck?

Life is too short. Be a supporter not a hater, or at the very least ignore those worlds and focus on where you can make an impact.

From mobile first to customer first; Organization and technical struggles @Scale

September 15, 2014 Leave a Comment

I am the @Scale conference again this year. Watching large companies (where large == more than just one product say) plan how they both structure their organizations as well as build their products, is top of mind, and last year both were at the forefront of the topics.

What I find interesting about @Scale is that the topics aren’t focused on cool technologies for startups, but more squarely on the issues that larger enterprises face.

I got to participate in today’s announcement that companies are coming together to collaborate via the TODO Group. The focus is to have a space to collaborate openly (mainly around open source). Good stuff.

Technology: Hybrid Fallacy

The constant debate over the last several years is “hybrid” vs. “Web”. I have talked about this again and again, and it obviously isn’t a binary choice.

We often assume that “hybrid” talked about means “using Web technology in native apps”, but in fact that is only one choice. Bret Taylor today talked about how Quip built its sync engine in C++ (helps to have great engineers who know C++ ;), and shares that across iOS, Android, and Web.

It is important to take note of the fact that the shared code is infrastructure code. We aren’t talking about using C++ as a toolkit that is doing anything with the UI tier.

There is a place for C++ in the UI. When you don’t care about the UI looking native. The typical example is “games”. Gaming companies have gotten a ton of leverage by building engines that can be customized for platforms. This can make sense for them as: a) they tend to want to ship to as many platforms as possible, and b) they can afford to build a custom UI. This isn’t true for the vast majority of your apps.

When it comes to the Web side of hybrid, it is good to know where the product (and or company) is coming from.

Some companies had the pleasure of starting in the “mobile first” era (a la Quip), but most “large” companies didn’t. Many of them have a ton of logic tied to the Web. Yup, still. When you talk to people at these companies they will often discuss how they are building services these days. Ask them if that is retrofitted across their products though.

From Web to Service

Let me mention our story at Walmart. When Ben and I landed there almost four years ago, there were no mobile applications, and barely a mobile oriented web site.

A “services” layer was being built, but it was backwards. The services were built on top of the web site. This lead to really bad side effects. Not all of the features were available (only those that were wrapped in a “service”), and the services were very brittle (changes to the web tier often broke services).

One of the reasons often used to “go hybrid” is to solve the problem of “we can’t get access to all of the features!”, where the root cause is actually “we need the services to be king”, and the solution could pop out of that. There are many questions to ask, including: How different are the various features across “all of the screens?”

There are plenty of use cases where the views are very similar between desktop, tablet, and mobile. Great! You can easily share the services and even potentially go hybrid.

However, I believe that the ideal situation is to have services exposing the functionality that each client needs, and to have native feeling UI on top of those services. You need to answer:

  • Can we pull off an acceptable UI? This depends partly on how complex a UI you think is suitable, and partly on what the hybrid tech has in terms of capability. Are you sure though that you don’t want to do something wicked cool natively? What about when you rotate the iPhone 6+ and go landscape!
  • Do we need to A/B test this puppy all the time? How much would it help to have different views in real-time? Do you want to / have you build an A/B solution that lets you do this natively? (e.g. return a DSL that the native UI can paint)
  • Is there complex view logic that makes sense to unify in one place? Really? even better than unifying it to product some simple JSON that represents the UI?

Our item pages are incredibly complex. There are a ton of different types of items, and that “page” is also a platform to surface content from a ton of other places (it touches almost every other commerce team). Should it be a hybrid Web component that is responsive?

The pro is that we can A/B test it, add functionality across the platforms easily, etc. The con is that we can’t do as many fancy native UI-isms. What if instead of a hybrid Web UI we had a clean description of the view that native could render? E.g. “Although there are 196 pieces of data to calculate something about an item, we always show some text under the image, so we can do that logic on the server and just return the info that the view can display there”.

NOTE: We go into a lil more nuance with our checkout hybrid implementation. The logic is done in JavaScript, but as we send events around the native app can swoop in and grab it, and render something natively. For example, if the customer wants to ship a product to one of our stores, the app can show the native mapping / store finder component and then when it gets the store, it sends it back over to the JS bridge.

Organization: Customer First not Mobile First

There are many trade offs on the technical side, but what is equally (if not more) important is marrying together the people side of the equation.

In 2014 we are beyond “mobile first”. There are plenty of screens, and your customer can interface with your service from any of them. When the mobile revolution kicked off many built out small “mobile” teams to move fast in the new world. There were few engineers who really knew mobile, so the laws of supply and demand lead to the forming of consulting groups who could “get value” from the companies. At this point, we still have consulting companies helping with mobile, but many more companies have in house engineering efforts (as well).

Having the “mobile” team allows you to move fast, but breaks down. For example, at Walmart we were able to scale out a very small team to quickly build experiences across iOS, Android, mWeb and various countries (not just Walmart in the US). The results were the largest revenue growth that I have been involved in.

The trade offs become real. When you have a silo, the side effects can creep in:

  • The “mobile PM” for X and the “desktop PM for X” argue about features (who decides?)
  • The mobile organization has different priorities than other parts of the organization (who decides?)
  • The mobile organization starts small is heavy in domain knowledge for mobile platforms, but lighter on domain knowledge on the problem domain (e.g. “I work on the iOS app and this sprint am doing some item page work” vs. “I work on the item page and grok the complex requirements of the catalog”).

Moving from platform teams to vertical teams is key. Uber talked about their migration, and it mirrors many that I have seen recently.

Vertical Teams

The vertical teams are focused on a product for the customer. E.g. “I work on the Walmart Photo team”. They have their own vision, mission, backlogs, and roadmaps. They control as much of their destiny as possible. It is unrealistic to say they control the entirety, because chances are they will be interfacing with other groups (e.g. “We work with the Checkout team to do commerce around photos”). As the products get larger, new vertical teams are created to serve that purpose.

Platform Teams

We see horizontal teams to deal with a couple different issues:

#1 Leverage components

When we see that we are solving the same problem three times (across teams), take a look to build a leveraged component or framework (but not prematurely!)

#2 Leverage knowledge

Your company may not have an army of iOS experts. How do you spread the love? We don’t believe in ivory tower architects who just tell you what to do and how to do it, but we do believe in having our best engineers help bring up the level of all of the engineers. It also helps with spreading knowledge between the pillars “oh interesting, the Pharmacy team had to build something just like that, we should talk to them” or “we actually have something in the platform that can help there…”.

#3 Help teams learn

We need to train the vertical teams to be able to own their own codebase across the platforms that they support. This involved “training”, but nothing is better than working with a great engineer. To counter the “architect” what if instead of the rules and enforcement, the following happens: “The photo team has a feature that really pushes the native barriers, so Bob from the platform team is going to join for a couple sprints to a) help them build it and b) look at how we can bring something back to the platform”.

#3 Keeping an eye on cross cutting concerns

When you are in a vertical team you are going to be running as fast as possible to meet your KPIs. In general the team will push on features, so it helps to balance this a touch with keeping the technical debt down and helping performance and other meta concerns.

Tribes

iOS engineers want to be able to talk about iOS engineering issues. This is where the notion of a tribe comes in. As you move from the “iOS team” to vertical and platform teams, you want to keep the iOS-y communication up. It is important to grow the tribe and have them feel like a cohesive group, even if they are a virtual group.

Diversity

A core value that sticks out for me is diversity. This cuts across both the technology and people layers. It is great for teams to try new ideas. We need experiments to learn from, and need to balance this with “every team uses a different Web framework” (which is where the platform teams come in).

In the name of diversity, we have room for both “full stack” engineers, as well as “highly focused” ones. If you care deeply about front end iOS work, there is room for you (there is plenty of this work, more than we can ever get done in fact…. [hint: we are hiring ;)]). Also, if you love to jump between the backend and front-end sprint to sprint that is great too! This flexibility means that the team can cross pollinate nicely and folks can load balance on the bottlenecks. Midfield soccer players and “football” kickers are all very welcome.

I am excited to see us trend to vertical teams and get the balances “right” with respect to the platform teams. There should be a natural tension here, and as with all tensions I don’t look for a false world where there are no conflicts, but instead look to see how conflicts are resolved. If issues fester, the process is broken.

Meetings with too many people suck

September 8, 2014 Leave a Comment


Have too many people in a meeting and it sucks. Everyone knows this!

The problem is that the reverse is often worse. Not having enough people in the meetings. Why? You end up with a cascade of a ton of meetings.

If you have people in a meeting you are taking them away from something else they can be doing. If you have this noble realization you are paranoid about the number of folks that you invite to a meeting. You don’t want to waste anyones time.

The perfect meeting has the smallest number of people who can make the right decision and disseminate the outcomes to the people that need to know of them.

Well, wait a minute, are all meetings equal?

No. There are actually different types of meetings, with different styles and goals. Is the meeting to get info across to a set of people? Are you looking to have a “working meeting” (hilarious term) to actually tackle a problem?

Flippin’ Aye

We have all been in those meetings where you wonder “why am I here? couldn’t this info be sent in an email?” These are painful and a huge waste of time for a team. They normally fall into the “lecture” format, having someone up front telling you some information. This isn’t engaging, and you sitting there doesn’t add value.

Don’t these sometimes remind you of lectures at school? Weren’t those classes painful too? Yes. Fortunately, we are starting to see some changes to the way that we teach, such as flip teaching.

Instead of having a professor lecture a large number of seated students (as they maybe try to stay awake), instead the resources (which could even be a recording of the lecture) are available before hand. The students are expected to have gone through the information, and then the classroom time is spent with engaging conversation. Don’t just take the info as rote truth, argue! What don’t you understand? Maybe you can go through some problems together? Much more engaging and practical.

Imagine if your next all hands was handled that way? Instead of some execs getting up on stage, what if you had been given a handout and could then come in and ask questions? Make the time worth while?

If you can’t? Don’t have the meeting.

Solving the problem with the right problem solvers

When you have the “too small” meetings, you are really seeing that the right problem solvers for the situation aren’t in the room. Meeting One ends up with one conclusion, but that decision gets messaged down the chain and someone with good information points out how that can’t actually work. You now end up bouncing around as sub-meetings are created to gather more info and you get into a cycle that ends up with a huge number of meetings.

The original person had their heart in the right place but inadvertently created a cascading storm. Whoops.

Capturing Decisions

I have been trying to capture decisions along with the data that was the basis of said decisions. I have found that over time a team can second guess, or come around to the same questions again and again. Revisiting something isn’t all bad, as the context and data may have changed, but having an audit trail enables me to tighten the cycle “anything changed? nope… ok can move on!”

Slacking off

It has been fun to see more teams use tools such as Slack to jump into vs. F2F meetings or email. There is a place for the different tools, but we seem to be getting a little better at choosing the right tool for the job.

This is critical as I really want to have people more able to focus on productive work vs. wasteful meetings. This doesn’t mean that meetings are all bad, as it is critical to have a shared consciousness in your team.

The cost of creating a meeting request in your calendar app doesn’t quite map to the potential productivity cost, so if you aren’t vigilant your time is taken from you.

The battle for balance continues.

« Previous Page

Primary Sidebar

Twitter

My Tweets

Recent Posts

  • The Pursuit of Taller Hills: Lessons from Football and Product Management
  • Building a modern design system in layers
  • Google A/I/O 2023: In Person Matters
  • Help Mario Reach The Next Platform!
  • I have scissors all over my house

Follow

  • LinkedIn
  • Medium
  • RSS
  • Twitter

Tags

3d Touch 2016 Active Recall Adaptive Design Agile Amazon Echo Android Android Development Apple Application Apps Artificial Intelligence Autocorrect blog Bots Brain Calendar Career Advice Cloud Computing Coding Cognitive Bias Commerce Communication Companies Conference Consciousness Cooking Cricket Cross Platform Deadline Delivery Design Design Systems Desktop Developer Advocacy Developer Experience Developer Platform Developer Productivity Developer Relations Developers Developer Tools Development Distributed Teams Documentation DX Ecosystem Education Energy Engineering Engineering Mangement Entrepreneurship Exercise Family Fitness Football Founders Future GenAI Gender Equality Google Google Developer Google IO Habits Health Hill Climbing HR Integrations JavaScript Jobs Jquery Kids Stories Kotlin Language Leadership Learning Lottery Machine Learning Management Messaging Metrics Micro Learning Microservices Microsoft Mobile Mobile App Development Mobile Apps Mobile Web Moving On NPM Open Source Organization Organization Design Pair Programming Paren Parenting Path Performance Platform Platform Thinking Politics Product Design Product Development Productivity Product Management Product Metrics Programming Progress Progressive Enhancement Progressive Web App Project Management Psychology Push Notifications pwa QA Rails React Reactive Remix Remote Working Resilience Ruby on Rails Screentime Self Improvement Service Worker Sharing Economy Shipping Shopify Short Story Silicon Valley Slack Soccer Software Software Development Spaced Repetition Speaking Startup Steve Jobs Study Teaching Team Building Tech Tech Ecosystems Technical Writing Technology Tools Transportation TV Series Twitter Typescript Uber UI Unknown User Experience User Testing UX vitals Voice Walmart Web Web Components Web Development Web Extensions Web Frameworks Web Performance Web Platform WWDC Yarn

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

  • May 2023
  • March 2023
  • February 2023
  • January 2023
  • September 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • November 2021
  • August 2021
  • July 2021
  • February 2021
  • January 2021
  • May 2020
  • April 2020
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • January 2019
  • October 2018
  • August 2018
  • July 2018
  • May 2018
  • February 2018
  • December 2017
  • November 2017
  • September 2017
  • August 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012

Search

Subscribe

RSS feed RSS - Posts

The right thing to do, is the right thing to do.

The right thing to do, is the right thing to do.

Dion Almaer

Copyright © 2023 · Log in

 

Loading Comments...