Profile

Cover photo
Max Kanat-Alexander
Works at Google
Attended University of California Santa Cruz
Lives in Mountain View, CA
629 followers|14,629 views
AboutPostsPhotosYouTube
People
In his circles
364 people
Have him in circles
629 people
Holly Iris's profile photo
Dave Heagney Jr's profile photo
Jessika Lindstrom's profile photo
Work
Occupation
Software Engineer
Employment
  • Google
    Software Engineer, 2011 - present
  • BugzillaSource, Inc.
    Chief Engineer, 2005 - 2011
Places
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Currently
Mountain View, CA
Previously
Santa Cruz, CA - Greenbrae, CA - Clearwater, FL - Winter Park, FL - Simi Valley, CA - Los Angeles, CA
Contact Information
Work
Email
Story
Tagline
Google, YouTube, Code Simplicity
Introduction
I'm the author of Code Simplicity: The Fundamentals of Softwarefedorafaq.org and codesimplicity.com. I was the Chief Architect of the Bugzilla Project, then the Tech Lead for YouTube on the Xbox. Now I'm the Technical Lead for Developer Solutions at YouTube, which means that I help establish development processes and improve development productivity for all internal YouTube developers at Google. I also write songs, play guitar, and sing.
Education
  • University of California Santa Cruz
    1999 - 2003
  • Redwood High School
    1996 - 1999
  • Tampa Preparatory School
    1995 - 1996
  • Country Day Academy
    1993 - 1995
  • Delphian School
    1992 - 1993
  • Hollow Hills Elementary School
Basic Information
Gender
Male
Other names
Maxwell

Stream

 
Software development can essentially be summed up as "taking the right actions in the right sequence." That sounds simplistic, but actually it's somewhat profound if you realize that it's the basic fundamental behind how we should think as software designers. Very often, we know the right actions to take, but if we take them in the wrong sequence, then a disaster results.

The easiest examples of this are in the field of code quality. "Write a lot of messy code and then clean it up" is a set of good actions in the wrong sequence. A better sequence is "write some code, then redesign while writing the next piece, and so on," as I cover in the chapter on Incremental Design in Code Simplicity.

This principle also explains why "launch and iterate" sometimes works and sometimes doesn't. It's about the sequence of features to implement, at what point you put user feedback into that sequence, and so forth. Saying "launch and iterate" is not enough, because it doesn't describe a whole development sequence.

This is similarly true with other common development philosophies--they work only so far as they produce the correct actions in the correct sequence. And since the correctness of actions depends on the specifics of a situation, the more "rigid" a philosophy is, the less likely it's going to work everywhere. That's one of the reasons I focused on helping people think rather than telling them what to do, in the book.

Anyhow, in general I suspect that all of software development can be summed up in one word, and that word is SEQUENCE.
4
1
Feiye Yew's profile photoAdil Zeshan's profile photo
 
Sequence is such a key word that I very much appreciated as I study mathematics.  Thank you for sharing.
Add a comment...
 
Here's me discussing the Third Flaw--I find this one hits senior engineers from time to time, in particular.
 
3 Flaws In Software Design: Part 3: Being Too Generic
#design   #developers   #software  

In part three of the series, +Jeremy Walker & +Max Kanat-Alexander  discuss the third Flaw in Software Design, "Being Too Generic," from Max's book Code Simplicity: The Fundamentals of Software.

Link to presentation: http://goo.gl/h73nY3
7
1
Michael Powell's profile photoJochen Wiedmann's profile photosiddharth nagavarapu's profile photoTed Bouskill's profile photo
11 comments
 
There is one point where +Max Kanat-Alexander mentions his approach to duplication: two is too many. This is a pretty common perspective.

5 copies of almost the same simple code will usually be effectively more complicated than one more generic solution that handles all of them. The trick is that when you're making the more generic solution you want to avoid the temptation to try and some problems you don't have to. Don't genericize it more than you need to.
Add a comment...
 
I did a series of talks recently for +Google Developers on the Three Flaws of Software Design. Here's the first in the series: Writing Code That Isn't Needed.
 
3 Flaws In Software Design: Part 1: Writing Code That's Not Needed

This week, we'll be sharing a four part series on software design flaws, featuring +Jeremy Walker and +Max Kanat-Alexander. Today, in part one, they discuss the first Flaw of Software Design, "Writing Code that isn't Needed," from Max's book Code Simplicity: The Fundamentals of Software.

You can also view the full presentation: http://goo.gl/h73nY3
8
1
Yau Ri's profile photoMax Kanat-Alexander's profile photoMichael Powell's profile photoStephen Charman's profile photo
4 comments
 
+Stephen Charman Sweet! :-)
Add a comment...
 
I really liked Philipp Seymour Hoffman. And it's true that the fact that he is dead is unfortunate and tragic. But it's also great that he gave us so many incredible performances, which we have recorded basically forever and can see any time we want, sometimes just for a few dollars.

The real tragedy would have been if he had died without giving any of those things to the world. If he had accepted too much criticism, or if he had somehow been convinced his goals weren't important enough to persue through hardship. So yes, though we should take this as another reminder on the danger of (most likely) drugs, we should also take it as a reminder that our goals are worthwhile, and think a bit about what we are going to leave behind when we go. Sometimes life ends up being shorter than expected, but if you're Philipp Seymour Hoffman, you've still taken that time to contribute something inspiring and beautiful to the world. I think any of us would be proud to say the same, no?
2
Add a comment...

Max Kanat-Alexander

Shared publicly  - 
 
 
Google Security is Hiring!

I’m looking for talented individuals to join Google’s Information Security Engineering team in a variety of roles and projects, and in various global locations. 

You can apply for some specific roles via the links below, but feel free to contact me directly too (via G+ or @subvurt on Twitter). We are working on some of the most interesting challenges in information security; we help build and secure cutting-edge software and hardware projects used by hundreds of millions of users worldwide.

We’re looking for people with diverse skill sets in both attack and defense; some roles emphasize software development whereas others are more focussed on application testing, penetration testing or vulnerability research.  We are also always looking for great Technical Program Managers and Product Managers to help keep us organized and on track!

I’m particularly interested to hear from folk who are active contributors to the security community as we strongly encourage such participation: many of our colleagues work on open source projects such as OpenSSH, OpenBSD, or develop free testing tools in their spare time. Quite a few of us are also involved in security vulnerability research, or efforts such as our Vulnerability Reward Program or Patch Reward Program.

Please do re-share if you know anyone who might be interested in this post!

Information Security Engineer, Google Plus

http://goo.gl/0f1YN0

Information Security Engineer

http://goo.gl/L5lkdR

Data Privacy Engineer, Privacy Red Team

http://goo.gl/OYfo0N
1
Add a comment...
In his circles
364 people
Have him in circles
629 people
Holly Iris's profile photo
Dave Heagney Jr's profile photo
Jessika Lindstrom's profile photo

Max Kanat-Alexander

Shared publicly  - 
 
I discuss Incremental Development and Design with +Google Developers.
7
4
Andre Untiedt's profile photoRashid Omar's profile photoStephen Charman's profile photoTed Bouskill's profile photo
3 comments
 
I can confirm the difficulty of adding unit tests later.  Thank you!
Add a comment...
 
Here's part 2 of my talk with +Google Developers.
 
3 Flaws In Software Design: Part 2: Not Making the Code Easy to Change

In part two of the series, +Jeremy Walker and +Max Kanat-Alexander  discuss the second Flaw of Software Design, "Not Making the Code Easy to Change," from Max's book Code Simplicity: The Fundamentals of Software. Also see the full presentation: http://goo.gl/h73nY3
5
1
Yau Ri's profile photoMax Kanat-Alexander's profile photoAndre Untiedt's profile photoTed Bouskill's profile photo
5 comments
 
"Assume the requirements are gong to change."  Deep.
Add a comment...
 
As of today, I've been working at Google for three years.

I still love my job, my co-workers, and Google as a whole. All the good things you've heard about working here are true.

By the way, if you have a passion for software design, I have openings to work directly with me on code quality, development processes, and developer tools for YouTube. It's a huge job, actually, and I'd love for you to come help me. :-)
3
Michael Powell's profile photo
 
Huh. You started at Google almost exactly the same time I started at IMVU then. And have similarly positive feelings about it 3 years later.
Add a comment...
2
1
Michael Powell's profile photoPhilip Durbin's profile photo
 
When I first read this, something about it bothered me, but it took me a little while to pin down what it was.

It's that it's overly prescriptive. You've heard the old thing that some people are visual learners, and some audible learners, etc? It's a a cliche, but there's some truth there. For some people, sketching something out on a board is the best way to work through a difficult problem. For others, writing down the problem is far more effective. For others still, the best way is to talk through the problem with somebody else. And for some, the most effective way is to sit back, close their eyes, and think on it.

It's a very personal thing, and depends on how your brain works. The problem is not that thinking is a universally bad approach, but that it's what a lot of people default to even when it's not the optimal approach for them. The real reason for this, I think, is that it's the one approach to working through a difficult problem which doesn't require any special tools or external action. You just have to stop what you're doing and focus. No need to pull up a whiteboard, or write an e-mail, or find somebody to talk to. This makes it an easy default.

So it's a problem that people who don't solve problems effectively that way still try to do it, but I think it's very important to acknowledge that some people DO effectively solve problems that way.

For what it's worth, methods that work for me, in order of effectiveness, are: writing about them, talking them over with other people, and then thinking and drawing. Yes, I put drawing (your recommended approach) on about the same level as just thinking. I know drawing is very effective for others, though.
Add a comment...