<CharlieDigital/> Programming, Politics, and uhh…pineapples


What Alan Watts Can Teach Us About Leadership

Posted by Charles Chen

I was listening to a talk by Alan Watts and found one bit of advice that really connected to what I've learned about leading others.

The principle is that any time you -- as it were -- voluntarily let up control.

In other words, cease to cling to yourself; you have an excess of power because you are wasting energy all the time in self defense.

Trying to manage things, trying to force things to conform to your will.

The moment you stop doing that, that wasted energy is available.

Therefore you are in that sense -- having that energy available --  you are one with the divine principle; you have the energy.

When you are trying, however, to act as if you were god, that is to say you don't trust anybody and you are the dictator and you have to keep everybody in line you lose the divine energy because what you are simply doing is defending yourself.

One mistake that I've been guilty of is to try to force things to conform to my will on various projects (I still do it to varying degrees!).  It is usually with the best of intentions -- for a cleaner framework, a better product, a more efficient process -- but at the same time, it is true that a lot of energy is spent wasted in doing so.

What is the alternative, then?

I think Watts is right that a level of trust has to exist that the team around you can help you achieve your project goals.  Instead of expending the energy in controlling the members of the team, spend the energy in building that trust through training, mentorship, guidance, and giving up not just control, but responsibility.

Sometimes that trust will be unwarranted, but sometimes, that trust will pay itself back many-fold.


Office Lighting and Decision Making

Posted by Charles Chen

The results of an interesting study flashed across my news feed yesterday:

Another finding was that the perception of heat could affect the participants’ emotions. The research team said that this is because emotions are more intense under bright light; thus, leading to the perception that light is heat, which can trigger more intense emotions.

The team also found that bright light affects the kinds of decisions people make. Since the majority of people work during the day under bright lighting conditions, the researchers noted that most daily decisions are made under bright light, which intensifies emotions.

Accordingly, they suggest that turning the light lower may help people make more rational decisions, not to mention negotiate better settlements in a calmer manner.

Taking emotion out of decision making is one of the most important skills one can develop and maybe it can be as simple as installing more ambient lighting and turning off those (ugly) fluorescent lamps overhead!


Leadership and Innovation

Posted by Charles Chen

From Peopleware, 3rd Edition:

The propensity to lead without being given the authority to do so is what, in organizations, distinguishes people that can innovate and break free of the constraints that limit their competitors.  Innovation is all about leadership, and leadership is all about innovation.  The rarity of one is the direct result of the rarity of the other.  (p. 101)


How to Rock That Interview

Posted by Charles Chen

My sister-in-law pinged me for some tips to prepare for a long, multi-session interview coming up.

I've been on both ends as interviewer and interviewee (mostly interviewer) and I seem to have been pretty successful as far as interviews go, so here are my tips (your mileage may vary):

  1. There is no preparation. It's like an exam. Either you know your stuff or you don't. Zen out and accept that you may not be able to answer/know everything and that no amount of last minute cramming new material will help. The more you worry about the material the bigger of a problem you are creating for yourself because you'll just be more anxious.
  2. Have faith in what you do know. Whatever it is that you do know, you need to be able to communicate it effectively. You need to communicate your knowledge, your skills, and your character effectively.  You are in an interview because someone likes your resume and the experience that you have so you have to be able to communicate that experience effectively.
  3. Say "I don't know" if you don't know. I interview a lot of people and one of my pet peeves is when I give a tough question and the interviewee won't just say "I don't know". Sometimes, the questions are designed to be hard so if you don't know, don't dance around it and be frank so you don't waste anyone's time.
    1. If you really think it's an interesting question, you can say "Hmm, I don't know, but I've never thought about it like that..."
    2. Or "I don't have a background in that topic, but it's interesting, how would you approach it?"
    3. Or "Oh, that's an interesting question; I've honestly never thought about that before". That leads me to my next tip...

    This is, in fact, a trait that I am looking for in an interview because it lets me know that if an individual gets stuck, he will quickly raise his or her voice and let me know so I can help them get unstuck and that this individual is willing to ask for help.

  4. Make it conversational. The more you treat it like a grilling, the more it will feel like you're over a fire. I treat every interview like a conversation and treat every question like a conversational discussion. The interviewer is a conversation partner and not a superior or an interviewer. This also leaves a lasting impression on them because they feel like you are someone they can easily talk to and people like to work with people they can talk to.  Also, you are always free to turn the tables and interview your interviewer; remember, an interview is a two way street: they want to know if they should hire you and you want to know if you really want to work with these people.
  5. Dress sharp, watch your posture, and give a strong first impression. Harvard studies have shown that posture has a strong influence not only on how others perceive you but also how you perform. Stand up straight. Sit straight. Shoulders back. Project confidence but also look relaxed. Use hand gestures to help communicate. Make eye contact -- don't lock it, though -- that's freaky. Using full body communication is important but remember not to fidget. Basic stuff.
  6. Remember names and call people by names. When you meet someone and greet them, they will present themselves and always call them by their name immediately. Interviewer: "Hi, I'm James"; you: "Hi, James, I'm Lindsay, pleased to meet you". It's subliminal, but people like to hear their names and it helps you make an impression in your brain so you know who he was. At the end, repeat the interviewer's name: "James, I really appreciate your time".
  7. Don't forget to drink water. When you talk a lot, your mouth and throat will get dry and if you don't hydrate, it will impact your ability to speak. Hit the restroom when you get a chance, even if you don't "need' to go because if you get the urge during a discussion, it will distract you.
  8. And final tip is to create mental checkpoints. One thing that happens with me is that because I treat an interview as a conversation, it is easy to lose the original question or topic in a long discussion. So you have to make a mental checkpoint and be able to bring the discussion back to the original topic to answer the question. You don't want to be in a position where you have to ask "Sorry, what was the question?"

Why I Wear the Same Pair of Jeans Every Day

Posted by Charles Chen

From NPR Marketplace Morning Report, a fun look at tech fashion and what it says about the wearer:

Silicon Valley, of course, is known for its casual dress, which means t-shirts, jeans and sneakers. But don't be fooled, techies care a lot more about fashion than they let on. Or put another way, there’s a lot of code in the Silicon Valley dress code.

In fact, engineer Alexey Komissarouk boasted he could tell if people were in tech and what they did by just looking at their dress. I met him a few months ago at the FWD.us hackathon and I asked him to show me his super power. He agreed and we met in downtown Palo Alto.

Before we got started, Komissarouk explained that the Silicon Valley is full of tribes: there are the engineers, designers, product managers, salespeople, entrepreneurs and VCs. And each tribe has its uniform.

The engineers? T-shirts, jeans and hoodies, of course.

“Hoodie signals young talent,” said Dan Woods, a techie we stopped on the street.

Woods walked by us and Komissarouk nudged me and said, “That guy, he’s a VC.”

The tip off? A zippered v-neck sweater.

“That’s like classic VC and then you got the button down underneath it, that’s like the classic uniform,” Komissarouk said.

We stopped Woods and asked him. Turns out, he did work in venture capital, which is about when he got the sweater.

Turns out the uniform is a long time tradition in tech, says Erik Schnakenberg, a co-founder of Buck Mason, a start-up that sells men's clothing online.

"I wear a pair of jeans and a black t-shirt almost everyday," Schnakenberg said. "It's one less thing to think about."

In the fast-moving world of tec, the idea is to show that your'e not wasting precious time on something as vain as fashion. Schnakenberg  says the uniform hasn't changed much but tech is attracting a lot more of the cool kids and they care about fashion.

It's also why I keep my head shaved myself.  One less thing to think about when I roll out of bed.

President Obama is known to have strategies to minimize the non-essential decision making:

...at work it’s strictly blue or gray suits. “I’m trying to pare down decisions. I don’t want to make decisions about what I’m eating or wearing. Because I have too many other decisions to make,” he tells Lewis. “You need to focus your decision-making energy. You need to routinize yourself. You can’t be going through the day distracted by trivia.”


More Thoughts on Planning Office Spaces for Development

Posted by Charles Chen

A proposed rule of thumb for planning office spaces for development:

  1. Buy cheap desks.
  2. Buy expensive chairs.

Our office has it all wrong.  We have desks that are solid as a rock but probably $600+ and seats that are $99 Office Max specials (just a guess).  I suspect that this is the case with most offices where the planners spend a fortune on desks, dividers, cabinets, and so on (just go look up the prices of cubicle partitions from Hon or Steelcase) and go cheap on the seating.

The problem is that the majority of an office worker's time is spent sitting.  Splurge on the chair instead.  Don't go too cheap on the desks; Ikea Galants are perfectly stable, durable, lightweight, easy to hack, easy to refactor, cheap, and assembling them is a great team building exercise 🙂

There is no exception to this rule.  If you want sit-to-stand type desks, just get something like this:

Kangaroo Elite Sit-to-Stand

Kangaroo Elite Sit-to-Stand (yeah, it's $600, but a sit-to-stand desk easily costs $1000+)

As an added bonus: if you have top candidates coming into the office for interviews, they are far more likely to be impressed by fancy chairs than fancy desks.


Thoughts on Spatial Conditions for Optimal Collaborative Efficiency

Posted by Charles Chen

(Or in other words, how to arrange your office space)

As I have been working in the office more, I've started to think more about how to organize the office space to enhance the collaborative nature of our work.

A few weeks back, we were re-arranging our desks and I noticed how heavy they were and how un-conducive they were to refactoring.  They are L-shaped desks with the two sections held together by two meager screws and a metal plate.  Yet they were so heavy and unwieldy as to make them extremely difficult to move.

The thought occurred to me then why Ikea Galants are almost universally the office desk of choice for startups: they're cheap, they're sturdy, they're easy to move, they're open, and they're extremely hackable.

Google image search results for tech startup office.

Google image search results for tech startup office.

But beyond just the hardware, I've been thinking about how to improve our team's ability to collaborate as we are in a period that requires highly coordinated design and development to hit our very tight timeline.  One of the first things we did was cluster the core team members into one area of the office so that it's easy to turn around and talk to anyone and so that all members of the team can hear and jump in on any design discussion.

This has downsides, of course, as it can get noisy and it can be difficult for other members who need to concentrate.  However, my thought is that we should reuse the office rooms for private "thinking" or call areas with standing only desks (no seats) so that individuals who need temporary peace can move into an office but not get too comfortable.

My other thought has been that it is extremely important for the leaders, founders, CEO, president -- whomever, to sit with the team.  The reason is that these decision makers need to know what's going on -- especially so in a startup -- and it's difficult to do so if their time is spent behind closed doors away from the action.  Of course, there are times when important phone calls must be made or private discussions must be had, but again, the concept is to reserve the closed door rooms specifically for this purpose and only with standing desks.

An even bigger intangible is that having the leadership on the floor sets the tone for the team.  In fact, I sit with my back facing my developers so that each of them can see what I'm working on and what I'm not doing.  I'm not on Facebook, I'm not randomly browsing sites, I'm not sitting idle.  I think this has a motivational effect and helps the team realize that we're all in this together to make the magic happen and that I'm not asking any more of them than I am of myself.

One final important lesson I've learned is that walls are stupid:



Thoughts on Goal Oriented Leadership

Posted by Charles Chen

I've been thinking heavily on the topic of leadership for several days now and trying to understand what works and what doesn't.  I am currently in the midst of a massive and daring undertaking and putting tremendous demands on my team to deliver.

My challenge has been to keep that pressure from them and help streamline this process so that they can focus on delivering and hitting our milestones.  To achieve this, I've tried to step up my leadership and intensity.

I started with a daily stand-up meeting where we got around and discussed our plan for the day, but after just a few days, I thought to myself that it was too limiting if I set the goals for the team and dictated what they did.  Who's to say that I have the best idea on how to hit our goals?  Instead, I only set our team goal and let each member of the team set their own goals for the day.

The effectiveness of this approach is multifaceted:

The first is that it allows communication of the overall team goal.  All members of the team need to know the goal and the mission to succeed; they have to see the bigger picture so that they know that there is a condition for victory and success.

The second is that it allows them to be responsible to their own expectations.  Because the goals are set by themselves, if the goals are not achieved, it cannot be blamed on someone else setting unrealistic goals; each member is thus motivated by an internal force and not an external force.

The third is that you will get better ideas simply by having more brains work on the problem of identifying the goals that need to be achieved for success.

A goal oriented leader doesn't tell people to do things, but rather lets them set their goals and move all obstacles out of the path of achieving those goals.  The idea is to transform yourself from a manager of tasks to a coordinator of goals: communicate a team goal, let the members set their own goals, and what a leader should do is align all goals to the mission.

(Also, it helps to keep the team well fed)


More Thoughts on Object Oriented Code

Posted by Charles Chen

I've talked about writing object-oriented and domain-driven design before.

In talking with another dev this week, I think I have my simplest summary of object-oriented code yet: when  you are writing well written object oriented code, you'll know it by the questions being asked by your code.

So what does this mean?

A good example is the following:

FormData formData = GetFormData();

// Object-oriented? Not really:
bool isValid = FormDataUtil.IsValid(formData);

// Object-oriented:
bool isValid = formData.IsValid();

It's very subtle, but it's very easy to observe because you simply need to ask yourself if you are asking the questions to the right objects.  We don't ask FormDataUtil if the formData is valid, we ask the formData directly.

Primarily, what this will reflect is the principle of encapsulation.

When you are asking the right questions to the right objects, you'll find that the code is easier to read, easier to maintain, less fragile, and more natural to reuse.

If the code is well written, as first time users, we don't have to know that there is a class explicitly designed to validate the form data; we can find it easily on the class itself.

I don't think it gets any simpler than that and yet it is, to me, the very essence of what it means to write object-oriented code.


SharePoint’s Image Problem

Posted by Charles Chen

SharePoint has an image problem with many folks.

I've discussed it before, but I think I have a new perspective on the issue.

You see, I recently interviewed a candidate that was Microsoft Certified IT Professional: SharePoint Administrator 2010 and Microsoft Certified Professional Developer: SharePoint Developer 2010.  His resume looked impressive and promising, with many SharePoint projects under his belt.

He failed miserably on my moderate-advanced web developer assessment, skipping on nearly every single item in the assessment -- things that I think any mid-level web/.NET developer should know.

You see, the problem is not that SharePoint is inherently a weak platform or inherently un-scalable or inherently poorly performing, but that they've made the platform so approachable, so well documented, and built such a strong community of developers and developer evangelists around it, that anyone can get into it.

You don't need to know how garbage collection works or understand the difference between a Func and an Action (or even know what they are!) or what IL is.

You don't need to know how to write a generic class or how to refactor code to reduce complexity.

You don't need to know many of the higher level programming concepts of .NET or sound object oriented programming practices to build solutions on SharePoint because most of the time, you can just google it and find an example (Of course, most examples -- even the Microsoft MSDN ones -- are not meant for production code; they are merely designed to convey the concept and usage of a particular member in the library but not necessarily how to use it in an architecturally sound manner).

So therein lies the root of SharePoint's image problem: it's so easy to build basic solutions, a developer who is fundamentally weak on the .NET platform and fundamental web technologies like Javascript and CSS can be productive in many companies and even get Microsoft certified!  And then these developers are let loose on projects that ultimately under-deliver in one way or another.  Be that performance or usability or maintainability.

SharePoint is like the mystery basket on Chopped.  There is nothing inherently good or bad about those mystery ingredients but for the skill of the individual chefs who combine them through the application of experience, creativity, and technique to create a dish.  With different chefs, you will get drastically different results each round and the winners are usually the folks that have a fundamental understanding of the art and science of flavor and cooking as well as a deep understanding of the ingredients.

It is the same with SharePoint; it is nothing but a basket of ingredients (capabilities or features) to start from (a very generic one at that).  At the end, whether your dish is successful or not is a function of whether you have good chefs that understand the ingredients and understand the art and science of melding the ingredients into one harmonious amalgamation.  Likewise, it is important that when staffing for SharePoint projects, you focus not only on SharePoint, but also on the fundamentals of .NET, computer science, and good programming in general.

You can also think of it like a Porsche.  Give it to a typical housewife to drive around a track and you'll get very different results versus having Danica Patrick drive it.  Should it reflect poorly on the Porsche that the housewife couldn't push it anywhere near the limits?  Or is it a function of the driver?  Danica Patrick in a Corolla could probably lap my wife in a Porsche around a track.

The bottom line is that SharePoint, in my view, is just a platform and a good starting point for many enterprise applications.  When some SharePoint projects fail or fall short of expectations, the blame is often assigned to the platform (ingredients) and not to the folks doing the cooking (or driving).  SharePoint is indeed a tricky basket of ingredients and it still takes a skilled team of architects, developers, testers, and business analysts to put it together in a way that is palatable.