Author: Neil Green

Neil on Open Offices

Neil GreenLeave a comment

Research now indicates that open offices hurt collaboration, which has caused the tech industry to freeze in stunned disbelief. There have been no reports of Apple or Facebook scraping their spacious floorplans in favor of individual private offices. Office spaces for new or expanding tech companies are all still built with open floor plans, seemingly ignorant to data demonstrating their harm. It would seem that the leaders of tech companies are far more interested in maintaining the status quo than encouraging their employees to work together.

Humans are hard-wired to do what they have always done. We do not like change and will fight it even if it is in our best interest. When we have established a way of doing things, we doggedly stick to the way we know and ignore ideas that challenge our beliefs. The stubbornness of the general population in resisting change is a well-understood phenomenon, but the tech industry should hold itself to a higher standard. Surely, if any industry were to embrace research that challenged their preconceived notions, it would be the tech industry. The sad reality is that the tech industry, despite its relative youth, is just as susceptible to the inertia of bad ideas as industries that have been around for centuries.

The path out of our open-offices-are-good confirmation bias may be merely acknowledging that a bias exists. If we can admit that we have done something a certain way for so long that we no longer question its efficacy, perhaps an alternative would present itself. The strategy of tech leaders burying their heads in the sand, and pretending that they are ignorant of the open-offices-are-bad research benefits no one. Successful tech companies must abide by a simple truth: less collaboration means less innovation, and innovation is the life-blood of a tech company. In hampering collaboration by ignoring open-offices-are-bad research, a tech company practically guarantees its long, slow decline.

Podcast Version

Neil on Remote Work

Neil Green1 Comment

The reason the software development industry remains divided over remote work is that we do not have a measure of developer productivity. If the amount of work produced were the same regardless of if someone was working in an office or from their home, the case for remote work would be substantial. Without a means of productivity comparison, however, the industry is forced to view working remotely as a perk rather than an irrelevant aspect of getting work done.

There are a few well-intentioned but ultimately ineffective attempts at measuring software developer productivity in use today. The most common is asking developers to estimate small pieces of work, and then track the time to completion. The resulting numerical values are then used to extrapolate a generalized formula to derive productivity for the entire group. This approach fails – often spectacularly – due to estimates being at times hilariously inaccurate, as well as productivity varying wildly from developer-to-developer. Additionally, the nature of software is that a system designed to maximize reuse and minimize redundancy eliminates repetitive work that could be estimated reliably. The net result of these phenomena is that an objective measure of software developer productivity cannot be derived using contemporary software development practices.

With an objective measure of productivity out of reach, a subjective measure appears to be our only option. At first glance, this may seem to be a significant step backward from our attempts to arrive at objective measures. In practice, however, subjective measures tend to have the most practical value in predicting relative work output from one developer to another. Unfortunately, contemporary management practices require that all employees be treated equally regardless of their work output. The effect of this misguided attempt at fairness is that topics such as remote work cannot be discussed using even the most rudimentary assessment of productivity. If this situation were different, our policies would reflect the undeniable truth: some developers can be trusted to work remotely, and some cannot.

Podcast Version

Neil on Hard Work

Neil GreenLeave a comment

No one wants to work hard. Presented with a choice between being given something for free, and working for something, most people prefer getting something for nothing. When people learn that they must work hard to get something, they tend to look for something else that is easier to attain. While this might be acceptable for the general population, professional software developers must work hard to learn technical skills and keep those skills sharp, while also producing high-quality code under tight time constraints.

Software developers will often confuse working long hours for hard work. Some developers will brag that they worked overtime to complete a feature, but never admit that they spent most of those hours wasting time. Most developers can only manage around six consecutive hours of hard mental work a day, but companies often consider six hours of highly productive hard work less impressive than twelve hours that yields next to nothing. These corporate cultures will eventually teach hard-workers to stretch their work over long hours, which ultimately leads to laziness as developers become accustomed to not working hard.

Lazy software developers who do not want to work hard are commonplace, but you can choose the type of software developer you want to be. Are you happy doing the minimum and playing the game of appearing to work when you are not or do you want to push yourself to become the best version of a professional you can be? Choose wisely, as lazy software developers will tend to find it very difficult to have long, successful careers as their ability to produce large volumes of high-quality work diminishes and disappears due to a lack of use.

Podcast Version

Neil on Success Envy

Neil GreenLeave a comment

Satya Nadella wishes he had Tim Cook’s hardware business; Tim Cook wishes he had Mark Zuckerberg’s social network; Mark Zuckerberg wishes he had Satya Nadella’s enterprise clients. When the wealthiest people running the most valuable companies in the world are not satisfied with the success they have, what message do they send the rest of the tech industry? Their message is simple, unavoidable, and explicit: you can never have enough success.

When stated as, “No matter how much success you achieve, it will never be enough,” most reasonable people would agree that this must be incorrect. There must surely be a level of success that is “enough,” but why then does it seem that nothing we achieve is ever good enough? One theory is that we are hard-wired to envy the success of others and compare our accomplishments with theirs. When we feel that someone has something better than us, what we have seems to lose value. The tragedy is that when we achieve whatever it was that we desired, we find someone new who has something even better, and the cycle repeats.

Perhaps the problem is how we define “success.” If wealth is the measure of success, and money is the measure of wealth, and money is a numeric value with no upper-bounds, then you can never have enough success. Having enough money to be successful is the unresolvable equation that most people toil their entire lives to solve. The inescapable truth is that the only way to be satisfied with your level of success is not to equate success with money. Defining what you consider success independent of wealth allows you to be successful right now, no matter how much money you have. With this level of control over your future, how then should you choose to define success? That is up to you, but remember that a definition of success that is realistic and enjoyable will bring you more satisfaction than one that is unattainable and unfulfilling.

Podcast Version

Neil on Being Afraid

Neil GreenLeave a comment

Early in your career as a software developer, almost everything you will encounter will be scary. You will need to deal with learning new technologies, stressful interviews, strange team cultures, unfamiliar processes, and very often difficult people. Being afraid of the unknown is a normal reaction, and software developers continuously face things they don’t know. You cannot avoid feeling fear as it is an ingrained survival instinct, but you can control how you react to being frightened.

When a new technology becomes popular, there will always be people who object to learning it. When someone new joins a team, people complain about their new teammate. Introducing a new process will cause people to proclaim the old way was better. There will be no end to excuses, but never will people admit the simple truth: they are afraid of change. To be a software developer, you must accept that confronting strange things is an inescapable part of your profession. Therefore, to call yourself a professional, you must learn to face your fears and overcome them.

When you face something that makes you afraid, don’t ignore how you feel. Instead, embrace that being scared is a natural part of being human. Take a moment, breath, center yourself, and calm down. Figure out why you are reacting in fear to something that, in reality, poses no real threat to you. Why does a new technology intimidate you? What is causing you to be nervous when you work with different people? How does an unfamiliar process hurt you? Peel back the layers until you find your answers, and then reassess your situation. You will find that your fear is all in your head because you are in no danger. There was never any threat, only a lack of confidence. Belief in yourself is under your complete control, and therefore, so is your ability to control your reaction to being afraid.

Podcast Version

The relationship between determining technical feasibility and productivity

Neil Green3 Comments

This is an answer to a question asked by Ashvini Chaudhari in the “Agile and Lean Software Development” LinkedIn group:

Dear All , I m pursuing my PhD in Agile Software Engineering. I have a question regarding spike solution ” If we add spike in project development will it have effect on team velocity? and if yes what could be the parameters ? All the responses will be consider as a general opinion in my PhD thesis.

Read More »

I pity Tim Cook

Neil Green6 Comments

It’s clear the Job’s deathbed playbook has long since been used up. The Apple devices are getting worse and worse year over year, but Tim Cook has managed to drive shareholder value despite that. Apple is the most valuable company in the world – no one can take that away from Tim Cook; but Apple has fallen from grace, and as captain of the ship Tim Cook bears all the blame.

Read More »

Define your problem before picking a solution

Neil GreenLeave a comment

Our industry revels in coming up with solutions, but is quite poor at defining problems. This has resulted in an vast constellation of technological solutions, but with the majority of investment capital being centered around a small handful of banal consumer problems (Hailing Rides, Shopping Convenience, Entertainment, etc.) If we are to solve problems that are worth solving, we’re going to need to get better at defining our problems before we pick solutions.

Read More »