A better method for giving feedback – no more sandwiches.

Somewhere along the way, most people learn the sandwich method of giving feedback. The concept is wrapping bad news inside of good news to make it go down easy. The premise makes sense: positive stuff makes us feel good, and negative stuff makes us anxious. Wrap it all up in positivity and avoid anxiety.

However, we all know that our emotions are more complicated than that. I think the sandwich method is a little patronizing and suffers from poor execution. It also doesn’t account for the power of emotional inertia. Going from good news to bad news can be crippling, even if you end on a good note.

I learned a better way from an etiquette book. The original advice was found in a section on how to ask for a favor from someone you haven’t spoken to in a long time. Consider this:

Hi Becky! It’s been forever. I miss your wacky hats.
Let’s hang out soon!
By the way, could I put you down as a reference?

This is what most people do. It comes off a bit opportunistic – the finishing request usually makes the entire message feel fake. My trusty etiquette book recommended you always open with your request. This makes you come off direct and honest. If you do put in a request to hang out or a compliment, it comes off as genuine since it follows your request. There’s no “surprise ask” or puffing up the recipient.

Hi Becky! Could I put you down as a reference?

By the way – Let’s hang out soon! It’s been forever. I miss your wacky hats.

I like to follow this same format for feedback. Genuine direct feedback or request first (regardless of positive or negative), followed with a friendly positive close.

The main reason I don’t like the sandwich method is because I can identify when it’s being used on me and others. I noticed that because you have to come up with two positive notes, people get lazy with the second one. It usually sounds like this:

I like the green actions. Great use of color.
However, the typography is too inconsistent. For example, this particular font [link] shouldn’t be used. Also I added notes on updating the column widths to to match the standard.
Overall good work though!
Let me know when the revision is ready.

This shows the execution problem with the sandwich method. It doesn’t work with a weak ending statement. Another mistake people make is they deliver the positive statements as “I like x” phrases, and the negative statements as factual statements. This makes the positive statements come off weaker and the negative statements come off very direct. Consider this approach:

Concerning the design:

The typography is too inconsistent. For example, this particular font [link] shouldn’t be used. Also I added notes on updating the column widths to to match the standard.
The design of the block elements is exactly what I had envisioned. The use of color is great. I like that all the actions have green icons. Let me know when the revision is ready.

It’s a little different. I think the directness can be a bit jarring, but honesty breeds respect. I believe this method also makes the positive feedback sound more real. After getting feedback in this way for a while, you will approach feedback less emotionally and dismiss less of it, especially the good parts. Anytime you go from negative to positive, there’s a positive emotional inertia effect along the lines of “it could always be worse.” If you start positive, and start peppering in criticism, the message is “it’s going to keep getting worse.”

Adults that respect each other give each other straight, but polite feedback. The sandwich method is a cheap cop-out and it doesn’t always sound as good as you intend it to.

Thoughts? Feedback? Sandwiches?

What is Art?

Leo Tolstoy wrote a short book called What is Art? defining art as a cultural form of communication, which might only be judged by its appropriate audience. He opposed those who judged art by beauty. He emphasized that anything can be art: jokes, home decorations, flower arrangement, religious rituals, etc.

Art is not, as the metaphysicians say, the manifestation of some mysterious idea of beauty or God; it is not, as the aesthetical physiologists say, a game in which man lets off his excess of stored-up energy; it is not the expression of man’s emotions by external signs; it is not the production of pleasing objects; and, above all, it is not pleasure; but it is a means of union among men, joining them together in the same feelings, and indispensable for the life and progress toward well-being of individuals and of humanity.

What I love most about this definition of art is that it implores us to appreciate many more moments on a deeper level. If most things are art, and art is indispensable to our well-being, then that means there’s interest all around us. That is, if only we were willing to appreciate more dad jokes, tedious rituals, hand-made tablecloths, dying floral arrangements, and homemade soundcloud rappers.

I always had an inkling that beauty was all around us, but What is Art? made me finally see it.

The AI innovations of the last two decades in simple English

In 1997, a little game called Age of Empires came out. For those of you not familiar with it, it’s a real-time strategy game where you create and arrange different pieces of a civilization in order to advance through different ages and defeat your enemies! To start, you create villagers that collect resources. Later on, you use those resources to update various technologies or create military or other units to support your goal of world domination.

You can play against other players, but you can also play against an AI player. A year later, Age of Empires II came out, with slightly improved gameplay and AI. The AI in both of these games highlight the limitations and design style of artificial intelligence systems of that era.

AI in the 90s

The original AI is marked by some very predictable patterns for each level of difficulty. The hardest difficulty of AI notably cheats – it gets more resources by default. Other than this, the AI has a pretty standard modus operandi – it builds an army made up of 1 or 2 unit types, which is not considered diverse enough by most players. On a forum discussing this topic, a player noted that a distinct feature of the original AI is “you can start to predict what it’s going to do after 1-2 games.” While the AI is reactive to its circumstances, it operates based on some pre-defined paths. For example, the AI is not smart enough to gauge that in certain battles, retreat is better. The AI simply goes from directive to directive: gain more resources, attack (keep attacking no matter what), and so on. The computer pays no mind to the variations in your play – it tends to behave the same way over and over.

The very first AI couldn’t even build walls around settlements. This was fixed in 1999.

Over time, new installments of the game added features to the AI, such as messaging. The AI would pick out of 30 or so canned messages to threaten you every so often, sometimes reacting to your behavior in the game. It was entertaining, but still fairly limited.

The best feature of the original AI was unit movement. AI can always outrun you. Unit speed is often based on a pretty difficult calculation of multiple bonuses that stack. As a human player you click around trying to run away as fast as possible, but AI can easily move the perfect angle based on the unit’s calculated speed to avoid attack and quickly move back to attack you. For this reason, beginner players still lose against AI in small battles that heavily depend on the angles you move your units along. This feature seems to be the same or slightly better today, with no major changes.

So far, we have artificial intelligence that has a couple pre-defined actions it can take. During the game, it will calculate benefits and losses in order to decide actions. Once it chooses an action, it does not stop (no retreats.) Additionally, the AI is great at fast geometric calculations, making unit movement far superior to what most humans are capable of.

AI Today

To truly explain the difference between then and now, we can look at the rebooted version of Age of Empires II: HD Edition.

The new AI calculates the benefit and loss of every single micro-decision. Instead of having a bulk action like, “Make a new mine and set 3 villagers on it,” it will decide every individual action separately based on what is happening. Let’s say a mine is needed. It will begin building the mine. If something happens – say, an attack on the other side of the map, it will cancel the mine if there is a more efficient action.

Let’s assume a mine is built. At this point, it will assess again, can I afford to still put a villager on this mine? If nothing changed in the last few minutes, the answer is most likely yes. It will make the decision on how many villagers to put on the mine and how fast based on what is happening on the entire map economically and militarily.

In certain cases, it might put 3 villagers on the mine exactly like the original AI, but in all the edge cases which make or break games, it will behave quite differently from the original AI.

Not only does the modern AI make smaller individual decisions, it also accesses many more data points. The goal was to mimic the decision making process of real human players. In fact, players of this game describe the new AI as “strategizing like a human being.”

That’s cool, but not mind-blowing

Well, it’s not. The advances behind modern AI are rooted in hardware. The original developers of Age of Empires were definitely smart enough to mimic a human’s strategizing, but no consumer machines would be able to do that much processing without slowing down the game.

While AI varies by application, I think this is a good sampler of the last two decades of development. Software developers simply trail hardware. As hardware gets cheaper and faster, software AI will be able to collect much more data, process it much faster, and make decisions much more often, leading to higher quality results. The modern AI quality is generally smarter than humans, if only because we can no longer easily predict the behavior of AI systems in order to out-strategize them.

That being said, tons of people have managed to beat the hardest new AI. Youtube has plenty of examples of wins against the hardest new AI within 20 minutes (Most human vs human games last 2+ hours.) We’re still winning. And by “we”, I mean very few humans who have mastered the game.

Does this surprise you?

Humans still have the ability to intuit, test theories, and deduce. The computer by default is aware of more data than we are – a human can’t possibly constantly calculate the cost and opportunity cost of a bunch of units using all different resources. It’s too much math. Humans still generally play with pre-set strategies (like the original AI) that change depending on circumstances (like the new AI.) On top of that, they have other skills and abilities we have not yet re-created. One example is experimenting and testing theories. It’s only a matter of time before these skills are also codified via machine learning and added to AI models, as long as there we have hardware fast enough to support it in real-time gameplay.

Moving past experimentation, humans also can compose and design. These are higher order types of thinking. We have modeled our emotional ranges fairly well, but haven’t figured out yet how to aid AI with emotion. My feeling is that emotion helps humans with decision-making much more than we think. What’s exciting about AI is that it forces us to think more and more about our own intelligence and mental abilities, figure out a way to model it, and then wait for the hardware that can run it.

Stop encouraging girls to code for a living

Some people argue that women lack the intelligence, are too emotional, or don’t handle stress well enough to be engineers. That’s not what this is about.

There’s groups out there who are driven by the idea that we need to get more women in engineering in America. I don’t get why. Women should do whatever they want, but why specifically push them to engineering?

To start, women in engineering (in Coastal America) are paid less, especially at the start of their careers. Women in their early 20s can be paid as little as 50% of what their male counterparts are paid. There’s a lot of reasons for this. My former professor Miriam Posner wrote an insightful article in The Guardian about this issue. All the while, the pay gap is closing in other industries, and in some, women are making more than men.

Engineering teams are hit and miss. No one wants to start a job anticipating they will have to talk to HR. I’ve worked on great engineering teams with amazing energy and lots of laughs, but I’ve also found myself in a handful of uncomfortable situations that don’t happen in marketing.

To get paid more – you have to switch jobs. This is pretty standard for everyone who codes. But switching jobs comes with a lot of questions for girls.

What kind of career can you have when you’re not really quite sure if you’ll be accepted at your next team? Along with the risk of being paid less, passed on for promotions, and generally tokenized – it ain’t a fun ride.

Jobs that have been traditionally done by men – construction, lifting heavy objects, repetitive tasks – are all at risk of automation. Women’s work – traditionally more empathy-based and requiring softer skills – will rise in demand in the next 5-10 years and will not be automated for a while longer. It is important for women to focus on their soft skills, especially leadership, listening, and people management. These skills are important to every field, even technical ones. Learning a specific technical skill is not as helpful long-term as, say, learning how to effectively communicate about technical problems with non-technical listeners.

So my advice to other women is: do 👏 literally 👏 anything else other than engineering. Be a youtube beauty guru. Start a for-profit career counseling firm for high schoolers. Go to clown school. Be an instagram model. I believe groups and organizations that heavily promote females in engineering are doing more to hurt women than to help them.

Keep in mind – I started coding as a child for fun. I had no idea what I was getting into and my parents were thrilled I was teaching myself stuff. To be fair, I come from a country where STEM is not male-dominated. I did not grow up with negative self-perception about my gender and technical careers, and I still don’t have any. I love building stuff with code! But I don’t really wanna work in engineering in the US, and I think it’s a fair choice.

Yes, if you want to code, definitely do it, but if you want to code for work, be fully aware of the risk you are taking every single time you accept a new gig. Engineering teams can be very aggressive, 4chan-like boys clubs, or they can be welcoming and supportive learning environments! I don’t think we should sugar-coat the gamble.

The Agile Conspiracy

There’s no conspiracy. But agile is a silly process for n00bs. So why are established companies who hire the best of the best still doing it?

Agile Software Development is a “set of principles” according to Wikipedia. I prefer to call it a productivity system. People don’t implement Agile because they are swayed to new principles in general, they implement it because they want their teams to ship more and better code, and hopefully, make more money.

I was introduced to Agile in 2014 when I came back to coding after getting my degree. I had previously worked on my own projects, a startup in San Jose, and the incubator Science. I also had contract work here and there – but these startup experiences formed my approach to coding and building web technology products. Of course, we didn’t use Agile. We didn’t use anything. There were no buzzwords and no meetings. If you had a question, you went and bothered the person if they were within walking distance, and texted, emailed, or called if otherwise. We simply gathered, discussed, planned, and everyone who was involved in creating was involved in planning. Every person was involved in asking questions. I would ask a lot of questions, I like to keep things written down, and I’ve never had a problem with this very simple system that everyone basically learns in school. Listening – Asking – Writing Down. I’m gonna call it LAWD and then charge $3,000 for seminars on how to implement it. Lawwwwwd, help us.

Why is Agile a “conspiracy?” Well, for one, it promises that it will save us from waterfall projects. Of course, I have never in my life worked on a waterfall project, because I’ve worked at startups mostly. I am not in danger of waterfall. Waterfall is Agile’s straw man.

Another thing Agile does is add layers of people between people by creating “Product Managers”.

Full disclosure: I am, ironically, a product manager.

I don’t think this role always fosters efficiency. I think the job that “Project Managers” do should be done by everyone on the team. Everyone should listen, ask questions, do research and be involved in planning the specific work that they are involved in. Product design decisions about a technical product should be made by whoever implements. For the following reasons:

  1.  The classic principle of “skin in the game.” If something goes wrong, a developer has to get on late and fix it. That developer may not have had a choice in designing the product in a way that would be better technically and better for his schedule. Not giving them the choice is the worst use of a technically skilled person. They, after all, are the expert on the topic. And they have the most to lose from a bad call – they have to lose the work they already did.
  2. Technical products need technical designers. If you decide how a technical product is built, you should know how to build one, and you should actually go through and build it. Even as a former engineer, the fact that I don’t actually build the products I plan and design give me a huge disadvantage. I find myself guessing when I shouldn’t be.
  3. In theory, a product owner would filter out information from stakeholders and pass it on. In practice, it becomes a game of telephone. Agile fosters misinformation just as much as when you build the mythical waterfall projects.

I believe Agile is a reaction to bad developers. Bad developers only care about code, have no interest in the product they are building or the goals of the business even though the code they are writing directly impacts it. Agile seems to push developers out of most of the process – and focus them on writing code. This is inefficient and boring for good developers. The skills web developers have give them a lot of power over the companies they work for. A good developer can assess the strengths and weaknesses of an implementation. They can spot areas for opportunity. By having nontechnical people plan technical products, we are throwing out most of the fun of development – which is being able to make a big difference with a small amount of work.

In the end, Agile is trying to simulate the experience of a small startup where a few people get together to build something by hand. It is a decent attempt, but not a great one. As someone new to product management, I have challenged myself to think about how to solve these problems. My first reaction has been to look at the team as a sports team, and dictate as little as possible. This requires that I’m a channel of communication. No matter how you look at it, the solution is clear from the start – the engineer needs to be in control of his work. How we get there with stakeholders on board is a process I am trying to figure out. Right now, I’m starting to think my role should be centered around talking to customers and users and not product design.

Agile is about productivity, output, and business outcome. I think business outcome should be the only goal. I think people should sit around and think about stuff. I think meetings should be random. Sometimes no output could mean better long-term outcome.* This is why Agile can be a trap.

*I’ve heard this concept referred to as sharpening the axe.