Category Archives: peopleware

Reductio ad absurdum of LinkedIn endorsements

John Lewis endorsed you for Inventory Management and Leadership

John Lewis endorsed you for Being Able to Help His Career and Always Being Nice to Him in the Breakroom When You Used to Work Together

John Lewis endorsed you for Wise Hiring Decisions and Giving People a Chance Even Though They Have Little Experience

John Lewis endorsed you for Seeing Him in Person at Build-a-Bear and Being Pleasant

John Lewis endorsed you for Pretending To Not Get Notifications from LinkedIn

John Lewis endorsed you for Ignoring Social Cues

John Lewis endorsed you for Passive Aggressiveness and Endorsing Him for Persistence

I’m writing a book about successfully working from home; signup if you want to know when it is complete.

Companies that support remote workers win against those that don’t

Years ago my boss asked if I could use a remote support developer in Europe for off-hours support of a critical system that processed data throughout the day.  He said that they had a sharp technical resource there who had normal working hours right in our support blind spot and that the candidate was interested in helping out.  I froze as the downsides flooded my mind:

  • He didn’t know our system at all.
  • I would never meet him.
  • We didn’t have much documentation of our systems.  All our knowledge transfer was done in person using heavy sarcasm and obscure hand waving.
  • We didn’t have a good ticket tracking system or history of service incidents we could point him at for self-study.
  • I wasn’t sure how I could judge whether or not he was helping or hurting.
  • I was afraid that instead of getting woken up in the middle of the night to solve a problem I would be woken up in the middle of the night to talk to him and explain the context because of the above problems.

All my objections were about how we weren’t ready to support him, monitor him, and grow him sitting where we sat as an immature support team. All my objections were things that we needed to change anyway and that he would serve as a canary and catalyst for these things to actually change.  We would be a better team by moving towards being able to support him.

***

With the developer job market being what it is  (i.e. a little nuts) some companies are offering work from home as an attractive add-on option – “Work from home Fridays”, “We support remote workers”, “Flexible schedule”.  This is being done as an after-thought and is not part of the core culture.

The difference between a company that can support a remote worker and one that cannot is not a small difference in perks: it is a chromosome-level difference. Companies that truly support remote workers win against those that don’t.

***

Having now myself been the remote person on the other side over the last 2+ years I’ve found a large range of differences between those that truly support remote work and those that just talk about it.  Think of it as the difference between a watch being water-resistant [you can wash your hands with it on] and diving-level waterproof [you can operate it underwater].

The reasoning is pretty simple: in order for a remote employee to succeed a company has to have clear communication, a standard process, and a clear focus on results above other secondary concerns.

A company has to provide the following:

  • A pipeline of work that is ready to actually be worked upon (It is packaged with its context and links to how to find out information for any questions)
  • Clear expectations for results and the ability to track how things are progressing.
  • Clear communication channels: this might include some permanence and search-ability for work already done but also includes some form of ~democratic decision-making that includes those that includes more people than can fit in a conference room.
  • A teaching culture that includes helpful coworkers ready to answer questions and help out remote workers if there are gaps of context.
  • A Results-Only-Work-Environment (ROWE) culture that allows workers to get as much done as they are able, and processes feedback from those workers about obstacles they encounter.

All of those things are good for the company supporting remote work even without a remote workforce – they create less friction around communication and infrastructure and make results the top priority.  In the end a company that focuses on primary complexity will beat those that are optimized for other things.

5 minute book review: Facts and Fallacies of Software Engineering

Facts and Fallacies of Software Engineering by Robert L. Glass is a fascinating little change of pace that I just finished reading. It was written by an academic-type (i.e. he may have a beard that he rubs while he talks) who also worked in the commercial the-code-has-to-work world. The book is laid out as 55 Facts and 10 Fallacies about software development across multiple topic groups.  In each Fact or Fallacy he states a conclusion, talks about any controversy surrounding the truth, and shows the underlying research.

A lot of the facts are well-known but they are still good to read since it shows you the theoretical underpinnings or empirical data. As an example I wasn’t aware of how much research has been done to prove this fact:

Understanding the existing product is the most difficult task of maintenance (Fact 44)

Some conclusions are well-stated versions of what many experienced programmers would nod their head to:

  • For every 25% increase in problem complexity, there is a 100% increase in solution complexity (Fact 21)
  • Error removal is the most time-consuming phase of the life cycle (Fact 31)
  • The best programmers are up to 28 times better than the worst programmers (Fact 2)
  • New tools and techniques cause an initial loss of productivity / quality (Fact 6)
  • Tacos are delicious (Fact -2)
  • Programmers like either Indian food or sushi but rarely both (Fact -3)

The list goes on and on. Some of the facts are a bit surprising and made me think:

  • Rigorous inspections [code reviews] can remove up to 90% of errors before the first test case is run (Fact 37)
  • Designer “primitives” (solutions programmers can readily code) rarely match programmer “primitives” (Fact 29)
  • Modification of reused code is particularly error-prone (Fact 19)
  • Better methods lead to more maintenance not less (Fact 45)

The Fallacies are even more interesting – Glass picks apart urban myths and particularly any thinking or techniques that are advocated by researchers and software salesmen that simply don’t work:

  • Software needs more methodologies (Fallacy 5)
  • Programming can and should be egoless (Fallacy 3)
  • Given enough eyeballs, all bugs are shallow (Fallacy 8)
  • You can teach people how to program by showing them how to write programs (Fallacy 10)

This book made me think, put into clear language some of my experiences, and was fascinating in that it exposed me to some research on software development. Recommended.

Vetting specialized developer experience

Let’s say your job today is to find people to work on a project that uses a crazy-cool-man-I-can’t-wait-to-show-my-old-high-school-girlfriend technology. Since everyone wants to try something new, improve their resume architecture, and dominate buzzword bingo you find that every single person you talk to about said technology appears to have “experience” with it.

(Sidebar, the technology is: Objective-MongoNodeGitDBBoneOnClojureCoffeeQueryTalkScript5 but we’ll call it HipsterScript)

The problem is that you aren’t (yet) the guru of said technology – you only know it from the knowledge gained by your research, protoyping, and decision to use it on your project. You are looking for someone to come in who is farther along to help you kickstart the project in the right way. You want to avoid the pitfalls, do things in the right way, and can’t afford to hire someone who is only a month ahead of you with said tool.

How do you separate those with real experience from the ones that have just read “Top 21 Pitfalls of HipsterScript, “How to scale HipsterScript to web scale”, and “Is HipsterScript right for your project?” merely a month ago?

Here are some things you can do:

#1 Ask directly:

We are looking for a combination of people who are either a) skilled and will learn quickly or b) people that have actual deep experience with this technology; we think you are skilled because we are talking to you, but are trying to get a feel for the other aspect, can you tell us more about your experience with HipsterScript

Listen to their answer. Then if it still isn’t obvious ask them to categorize their previous work into the following buckets:

Academic: reading articles, watching videos, playing around in the IDE / SDKs.
Laboratory: creating a system for their personal use with said technology; making said technology print your name, etc.
Maintenance Project: They were on a project that used said technology but they might not completely understand how/why it was used.
Project: They made heavy contributions using HipsterScript and understand why it was used rather than HipsterClojure.

#2 Assess Fanboy status:

Tell me what you hate the most about HipsterScript

Tell me what you shouldn’t do with HipsterScript

Inexperience means that you haven’t screwed up enough yet.  And with technology inexperience means that you still love the technology because you haven’t seen its limits – I loved ColdFusion until I tried to support a system with heavy customization with it, I loved Active Reports until I had to modify one to do a pixel-small change, I loved serializing everything as JSON until it got big and I didn’t.  Experience means exploring to the edges of the box.  If they have only had success with a certain tool that means they haven’t had a chance to really push it.

#3 Assess ability to learn

All this said you can’t only hire gurus in certain technologies – you want skilled people who can adjust.  After all – what if you find that HipsterScript doesn’t scale once you get spikey periods of high write to read ratios in your database layer?

Assessing if someone can learn is hard because most developers are really good at learning.  So I’ve found that judging moxie is more effective – anybody will tell you that they can take on a PHP project without actually ever hacking at PHP but you want to find people that routinely do this – only success with jumping in with new technologies indicates that a person can do it again.

Ask them about an experience in which they didn’t now a technology at the beginning of the project and did at the end.  Did they need a training class, a book, a few days alone with the Internet, did they use peers/their network to speed up learning?

Also, search the edges of their toolset – ask them how they learned about tools that most developers simply pickup as they work – regular expressions, algorithms, database scaling, reporting technologies, logging tools, exception-handling.  Did they just do the minimum or do they truly understand them?  How well they know these will be a good indicator of how intentional they are with mastering things and just making it work.

Good luck with your HipsterScript project.

 

Questions to ask in an interview

The questions you ask in a job interview are important.

They reveal your level of experience, ability to form complete sentences, how much you were actually listening, passion level, and how seriously you take committing to an organization. While the goal of an interview is to get an offer, deciding what to do with that offer requires you to proactively seek information.

Feel free to ask questions even if you get to the end of the interview and you’ve managed to:

  • pronounce C# as “C-tic-tac-toe-board”
  • use airquotes every time you said “database”
  • completely bomb the technical interview (“Sir once again – you use the other end of the whiteboard marker to write”)
  • made a joke so lame everyone just looked down in shame (“Well, I think I would fit here because I-BM’d this morning! Get it?“)

If the interview is going well the questions you ask will arm you with critical information to do the right things in your first months on the job, and if the interview is going badly insightful questions can still be valuable – every interview is an inside scoop on how a particular company operates, what they value, and a chance to meet new people who are good at what they do – don’t miss it.

How to ask hard questions

The real questions you want to ask are at times too direct; they are the equivalent of asking a first date overly-intimate questions (“So what does you mom look like – does she have that eyes-too-close- together-Will-Ferrell thing going on too?”). While figuring out what you can get away with is an art and not a science, I’ll offer these random bits from my own experience:

  • You’ll regret the question that you don’t ask. It will haunt your dreams and bring shame to your family
  • It’s much easier to read people 1-on-1. If an interview is six people each talking to you for 15 minutes you can pick and choose who to ask based on what you read off of people – who seems to like telling stories from the “good old days”, who is an engineer and therefore stereotypically honest, who is going to give you the brochure answer? [Side note – some of the best information can be gathered from asking good questions of multiple people and comparing notes]
  • If you get invited to a lunch interview it’s a much better situation than in an office; the bar is lowered and people are more honest with their answers.

In the end the basic information you are trying to pull out of the interview process:

  1. Is the work-life balance what I’m looking for?
  2. Is the risk/reward situation what I’m looking for?
  3. Will I fit in, learn, and thrive?
  4. What are they trying to do?
  5. What happens when things go wrong?

Is the work-life balance what I’m looking for?

First things first, I’ve seen the following three things crop up time and time again in my own personal experience as possible “two weeks later” deal-breakers that just aren’t always known upfront.

  • What percentage of travel is really expected? When is my first business trip? Is being on the road something that can affect how well I do here?
  • What is the real, honest, number of hours I’m expected to work? (The smaller the company the more important this question is)
  • “If Ricardo likes it then surely it is awesome so no further questions”. Research a company even if your friend works there. Sure you and your buddy worked great together at the last place, but little did you know he loves traveling, getting yelled at, and loud smelly office conditions and you don’t.

Will I fit in, learn, and thrive?

Is this a place where you see yourself being successful after 90 days? Do you see yourself liking or tolerating the people you’d work with and for? Will they help you to succeed?

  • Tell me about your mentoring and training strategies.
  • How many new hires have started in the last year?
  • What success rate are you seeing with new hires?
  • How has the company changed since you started working here?
  • Tell me a story that you are tired of hearing about this place.
  • What are you guys really bad at (i.e. what do you not value)?
  • Does anybody hang out together after work?
  • Has anybody here worked together elsewhere before?

Is the risk/reward situation what I’m looking for?

Before you leave you need to know how stable the company is and where it is on the risk/reward scale between a two person startup and the IRS. This is sometimes as simple as looking around and seeing how many people are in the building and how tired they look, but most of the time you need to dig deeper to confirm your gut feel:

  • How big is this industry?
  • Who are your competitors?
  • Give me a two minute company overview.
  • What are you current business challenges? (Dig deeper if the answers are: grow, become more profitable – how?)
  • When was the last time you had to perform layoffs?

What are they trying to do?

  • Why are you hiring?
  • Walk me through the architecture of your system(s).
  • What do you hate the most, and what’s the things you guys are most proud of?
  • What was the hardest part to get right?
  • What part of the system do you wish you could build?
  • What are you plans to fix your current problems? [Do people agree on the problems and solutions, or are they still up for debate?]
  • What sort of technical debt do you have?

What happens when things go wrong?

How a company acts when things go badly reveals who the company really is. In an interview they may paint the best possible picture, but asking about recent project delays is a great way to get passion and real information out of the interviewers.

  • Talk to me about the last time a project was late (or cancelled), and what actions were performed.
  • When you miss a milestone, do you start to track it more or less?
  • What has been your biggest project failure in the last year?
  • When a project is late, do you ever add people, and is it always the same group of people?
  • How does the client / industry react?
  • When things are behind do you expect more or less individual (vs. group) accountability?
  • Do you perform post mortems?

Speaking of post-mortems, make sure to be able to effectively close the interview by asking them if there is any additional information they need from you in order to make a hiring decision. Then hopefully in a few days you’ll be asked “When can you start?” and positioned with the knowledge mined in the interview you’ll be able to answer.

How to complain

Let’s talk about one of the ills facing any group of people who are passionate about their work – ‘complaining about how bad things are’.  I’ll list some personal do’s and don’ts on effective complaining, and ways that organizations can help it not destroy morale.Every person that cares about their job complains.  How they complain, the level of detail of the complaint, and who they complain to are different for each person. People complaining badly in an organization that isn’t listening will destroy morale and lead to the sort of stagnation that destroys good organizations.

Personal complaining

Complaining badly is a waste of your time. So, the rules:

Complain only to someone that can help you change what you are complaining about.

All other complaining is effectively gossip.  While it’s certainly not a bad idea to discuss possible solutions with coworkers, if you find yourself complaining about the same thing at lunch with your coworkers over and over without discussing solutions pat yourself on the back – you are part of the problem.

Don’t passively complain

Passive complaining is most complaining – “The government spends too much of my money.”, “I wish I was taller, I wish I was a baller”.  In a professional setting people need solutions.  If you complain about something, don’t let the complaint block you from a solution, and view the opportunity to give feedback as a chance to list problems and present your own solutions.

Common complaint patterns

“John sucks.  They should just replace John”

If they replaced him with you, what would your first actions be?  Take some time to think this over – imagine yourself giving suggestions directly to John.  Suggest those actions instead of replacing John.

What this company needs is leadership.  We need vision from above to tell us what to do.

Be more specific – do you need instruction on how to do your job, what to work on, or is there a clear vision ambiguity? If not, then you are basically sending the message: “I can’t self-manage, and need further instructions from my bosses to do important things.” Again, if you were in their position, what vision would you cast – what are your solutions?

If we could just take three months and clean-everything-up, then we’d be able to get our head above water.

The only companies that are able to stop current work and ‘clean-up’ are dying companies.  I hate to break it to you, but The Great Big Rewrite Of All Our Software isn’t going to happen.  Solutions that allow companies to continue working while improving are much more important than greenfield ones.  It’s a great exercise to actually write out a business case for the “Take three months” plan and really think through the true business value.  Pick five simple things that can be done now and figure out a way to do them.

We need better communication.

Be more specific – are two groups working on the same thing?  Is only half the office showing up to company parties?  Is half of the company selling poison while the other sells antidote? [Actually, that’s not a bad idea]  This statement is just too general.

Joe should be fired.

Even in extreme cases of ethical violations, the open criticism of someone in this way should be avoided.  In the extreme case the complaint should be registered with the proper channels given the rules above.  Focus should remain on the specific behaviors and consequences of said behaviors rather than the person, and you should feel comfortable telling the person directly everything that you tell anyone else.

This place sucks.  This has to be the worst-run company in the world.

If you aren’t allowed to complain, all solutions are blocked, and there is nobody to actually complain to you can still list out your complaints anyway.  You learn from every single experience if you allow yourself to pay attention and you never know when having your thoughts organized will help.

Organizational complaint handling

Let’s talk about the suggestion box.  You know, the one that people put old cigarettes in, and the one where in the movies some brilliant idea shows up from a low-level worker, causing them to rise to sudden fame?  The suggestion box is a sign of certain organizational fear of open criticism, not its opposite.  How can an organization accept open complaining without causing fear and demoralizing its employees?

First, only accept criticism that is inbounds.

See rules above.

Be open to criticism as a means to change.

When an employee complains ask questions, take notes, pay attention.  Even if you have heard the problem and same solution from a different person, tried it, watched the failure of it, and wept openly at the awkward post-mortem (“Seriously guys who thought the beanie baby Christmas bonus was a good idea?”) continue to listen to the new perspective.  The person in front of you is extending themselves and is passionate about the issue and dismissing them in anyway is dangerous.

Be open to criticism that follows chain of command, and discourage other forms.

Start conversations with “Have you talked to John about this?”  [Make sure that somebody named John works for you].Politics can destroy open communication of this form.  How to handle ideas within an organization is a larger subject, but in order to counteract the natural problems with the chain-of-command-only communication pattern, setup chances for higher level management to communicate with people in the details enough to see problems.  Sometimes the first level of management (tech leads, managers) cannot see process issues as they still have one foot in each camp.  In addition a more experienced manager might recognize a solution that others miss.

View complaints and criticism as a sign of a healthy organization, and don’t take it personally.  In the same way that hard conversations are needed in real relationships if you don’t hear complaining it’s a bad sign.  Your employees are complaining, but they might be doing it to the wrong people, and in the wrong way.

Fixing problems Part 1: Introduction and Attitude Adjustment

As DBAs, software developers, Homo Sapiens, and lovers we have to solve problems.  There is a common misconception that support is for the more junior folks on a team and thus being good at it is a sign of “being a little baby”.  While support is a great way to learn a software ecosystem and organization and thus “grow” a junior person into a senior one a lot of problem-solving falls to the rock star programmers or wizard DBAs in most organizations.

Yet some of these people aren’t any good at it.  In fact, they are awful.  I’ve seen people that are very good at doing very hard technical things – creating something from nothing, thinking of all the things that could go wrong, refactoring and integrating a large subsystem, etc. – fail at simply fixing a problem with an existing system. You can take your rock star and send them off to fix a support issue and they will return with a confused look, eight hours of wasted effort, a missing finger, and an STD.  Working with some truly gifted problem solvers I think that there are some differences in Attitude, Practices, and Skills that separate the junior and senior problem solvers.  Let’s start with Attitude.

First, there IS a problem

Never deny that there is a problem.  If someone is at your desk, on the phone, flooding your email with red exclamation points, or outside your house knocking on the window there is clearly a problem.  The problem might be that they don’t understand something and the problem might not be your fault, but the issue should be treated with respect as a real problem if they took the time to contact you.  Don’t deny it or argue.  Why would you deny it anyway, because you see support as negative.

Don’t see support as a negative shameful thing or a junior task

As long as things keep changing, there will always be problems.  (This next part is hard to put down in writing) If you aren’t writing bugs you aren’t writing software.  If you aren’t changing systems you aren’t working.  A support issue is not an insult, a bug is not a breakup.  Yes, you should make sure that you don’t write infinite loops, and yes you should make sure that you test the latest SQL Server upgrade before you install it in production at 10 am on the last day of the month.  But in most organizations there is a constant to and fro of creating new things and then fixing issues that crop up with them, so don’t pretend as if a problem is an anomaly.  True root cause and issue prevention are topics for another post, but don’t act surprised that software systems don’t always work as expected.

Confidence

In my home office I have a fortune cookie taped to one of my monitors that says: “You have the ability to analyze and solve any problem”, and over time I have started to believe it (by looking at it 27 times a minute).  The fact is that most people that are good at support are good because they believe that given enough time they could fix any issue.  ANY issue.  Given 20 years and enough coffee they could learn C/C++, reverse engineer SQL Server, learn about cross-platform multi-threading, and fix that bug.

The ability to not freak out and lose it

Something is broken but don’t be scared (its just moving electrons for the highest bidder).  The fact that someone is at your desk and not someone else’s is a good thing, don’t panic and freak out and yell things that you’ll regret later (Aside: yelling is always regretted – only thing I’ve not regretted yelling “OMG ITs MILEY”). Don’t blame people or come off as condescending; assume that they are your desk because they know you can fix it, not because they think you caused it.  Figuring out root cause and a long-term solution are separate things; as are fixing and blaming.  You are in charge of fixing for now, so just focus on that.  Besides, over time a calm person is going to be relied upon more while those freakout will only end up on reality shows.

Next post – Practices that improve your ability to fix complex technical issues.

Complexity

In software development there are three levels of complexity that are in play.  You should focus on the primary complexity: taking a complex business problem within its native domain and designing a technical solution.

Examples of primary complexity issues are designing a strategy-based plugin architecture for mortgage calculations, designing a star schema to later use for predictive analysis of snack cart Skittle consumption on college campuses (spoiler alert: finals week and wild berry are a solid marriage).  Secondary complexity in software include items that the folks in the domain don’t understand but the technical folks need to do their work quickly. The QA team, the fact that you need to upgrade Visual Studio every two years in a Microsoft shop, your check-in policy and coding standards – these are typical examples of secondary complexity.  Tertiary complexity are items that the domain folks and the technical folks don’t fully understand. The fact that Steve and Ralph freaking hate each other, the morale impact of low raises on a team, the fact that communication can kill a team over a certain size, poor meeting practice, etc. are all examples of tertiary complexity. This type of complexity is colloquially referred to as “bullshit” (in some provinces “horseshit” or more rarely “dogshit”)

Consequences

The levels affect each other predictably. If the problems of one level are not solved, they affect levels above them. If half of your team are French and the other half hate French people, that’s a tertiary complexity problem that will lead to awkward code reviews, poor rework throughput and affect your ability to ship software that solves domain problems. If your QA and UAT databases “timeout” more than a cranky 2 year old, you can’t ship software.

Talent Effect

By “effect” I don’t mean slow down only. If you have too many secondary and tertiary problems, the people that work in the primary domain will grow frustrated. In software development these are creators – developers and those that feed them information (BAs, User Interface folks, reedit). This is a dangerous situation. If you hire a talented pizza chef but all the pizza shows up two hours late (or not at all) you have secondary problems (failed delivery channel – broken down Civic) or tertiary problems (your delivery guy likes pot more than tips) eventually the chef will feel that their work doesn’t matter and leave.

Management

If you make the move from developer to manager, you are effectively saying that your team will handle the primary work while you work on secondary work (processes) with their input, but try as much as possible to shield the tertiary problems (bullshit) from them. Where this gets more complex is when tertiary complexity is high in an organization. The most striking example of tertiary complexity in some organizations are middle managers jockeying for promotion position – this activity does not improve processes or help with production, but creates a situation in which these things are harder.The balance of tertiary vs. secondary complexity is indicative of where a company is and whether it can heal its key problems. If the tertiary complexity is low, then there is enough management capacity to solve secondary issues and allow producers to create great things.