Software Developer Motivation Quotes

IF YOU DON’T FEED YOUR MIND WITH SUCCESS. IT WILL ROT WITH MEDIOCRITY!

Many rookie software managers think that they can "motivate" their programmers to work faster by giving them nice, "tight" (unrealistically short) schedules. I think this kind of motivation is brain-dead. When I'm behind schedule, I feel doomed and depressed and unmotivated. When I'm working ahead of schedule, I'm cheerful and productive. The schedule is not the place to play psychological games.

I believe humanity would develop their way forward quicker if a human didn't have to waste so much time on sleep and fighting countless software and device bugs.

As you’re reading through code, you will find things that you would have never done. You will find things you might have never even thought of. Why? What was the developer thinking? What were his or her motivations? You can even learn from bad code with this kind of critical, self-aware exploration of an existing work.

Being a leader doesn’t mean you have people reporting to you on an organizational chart—leadership is about inspiring and motivating those around you. A good leader affects a team’s ability to deliver code, architect good systems, and apply Lean principles to how the team manages its work and develops products. All of these have a measurable impact on an organization’s profitability, productivity, and market share.

Or, suppose you want to motivate your managers to ship products on time, so you conspicuously promote each manager whose product goes out the door on schedule. All goes as planned until the situation arises in which one of your managers has a project where the testers are reporting numerous problems. Because managers who have shipped products on time have been promoted, this manager thinks, I want that promotion so I need to ship this on time, but those bug reports are getting in the way. I know what I'll do! I'll put the testers on another project until the developers have a chance to catch up.

the critical factor in motivation is not measurement,8 but empowerment: moving decisions to the lowest possible level in an organization while developing the capacity of those people to make decisions wisely.

Management and the Liberal Arts Management is a liberal art. Management is what tradition used to call a liberal art—“liberal” because it deals with the fundamentals of knowledge, self-knowledge, wisdom, and leadership; “art” because it deals with practice and application. Managers draw upon all of the knowledges and insights of the humanities and social sciences—on psychology and philosophy, on economics and history, on the physical sciences and ethics. But they have to focus this knowledge on effectiveness and results—on healing a sick patient, teaching a student, building a bridge, designing and selling a “user-friendly” software program.   ACTION POINT: What is your plan to develop yourself in the humanities and social sciences? Develop such a plan today. The New Realities

One of the worst disconnects of a business software development effort is seen in the gap between domain experts and software developers. Generally speaking, true domain experts are focused on delivering business value. On the other hand, software developers are typically drawn to technology and technical solutions to business problems. It’s not that software developers have wrong motivations; it’s just what tends to grab their attention. Even when software developers engage with domain experts, the collaboration is largely at a surface level, and the software that gets developed often results in a translation/mapping between how the business thinks and operates and how the software developer interprets that. The resulting software generally does not reflect a recognizable realization of the mental model of the domain experts, or perhaps it does so only partially. Over time this disconnect becomes costly. The translation of domain knowledge into software is lost as developers transition to other projects or leave the company. A different, yet related problem is when one or more domain experts do not agree with each other. This tends to happen because each expert has more or less experience in the specific domain being modeled, or they are simply experts in related but different areas. It’s also common for multiple “domain experts” to have no expertise in a given domain, where they are more of a business analyst, yet they are expected to bring insightful direction to discussions. When this situation goes unchecked, it results in blurred rather than crisp mental models, which lead to conflicting software models. Worse still is when the technical approach to software development actually wrongly changes the way the business functions. While a different scenario, it is well known that enterprise resource planning (ERP) software will often change the overall business operations of an organization to fit the way the ERP functions. The total cost of owning the ERP cannot be fully calculated in terms of license and maintenance fees. The reorganization and disruption to the business can be far more costly than either of those two tangible factors. A similar dynamic is at play as your software development teams interpret what the business needs into what the newly developed software actually does. This can be both costly and disruptive to the business, its customers, and its partners. Furthermore, this technical interpretation is both unnecessary and avoidable with the use of proven software development techniques. The solution is a key investment.

Agile software development needs teams to be motivated. But repetitive tasks are boring, not motivating, so they should be automated. Many

Karim Lakhani and Boston Consulting Group consultant Bob Wolf surveyed 684 open-source developers, mostly in North America and Europe, about why they participated in these projects. Lakhani and Wolf uncovered a range of motives, but they found “that enjoyment-based intrinsic motivation, namely how creative a person feels when working on the project, is the strongest and most pervasive driver.”2 A large majority of programmers, the researchers discovered, reported that they frequently reached the state of optimal challenge called “flow.” Likewise, three German economists who studied open-source projects around the world found that what drives participants is “a set of predominantly intrinsic motives”—in particular, “the fun . . . of mastering the challenge of a given software problem” and the “desire to give a gift to the programmer community.”3 Motivation 2.0 has little room for these sorts of impulses.

Extreme Programming concentrates exclusively on the active elements of a program and executable tests. Even comments added to the code do not affect program behavior, so they always fall out of sync with the active code and its driving model. External documents and diagrams do not affect the behavior of the program, so they fall out of sync. On the other hand, spoken communication and ephemeral diagrams on whiteboards do not linger to create confusion. This dependence on the code as communication medium motivates developers to keep the code clean and transparent.

if we establish something as the “best possible way, the motivation for kaizen [continuous incremental improvement] will be gone

With highly motivated developers who have fun doing what they do and who are constantly looking outside their own cubicles, companies could benefit immensely from all the innovations and efficiencies they would bring.

The Linux world behaves in many respects like a free market or an ecology, a collection of selfish agents attempting to maximize utility which in the process produces a self-correcting spontaneous order more elaborate and efficient than any amount of central planning could have achieved. Here, then, is the place to seek the “principle of understanding”. The “utility function” Linux hackers are maximizing is not classically economic, but is the intangible of their own ego satisfaction and reputation among other hackers. (One may call their motivation “altruistic”, but this ignores the fact that altruism is itself a form of ego satisfaction for the altruist). Voluntary cultures that work this way are not actually uncommon; one other in which I have long participated is science fiction fandom, which unlike hackerdom has long explicitly recognized “egoboo” (ego-boosting, or the enhancement of one’s reputation among other fans) as the basic drive behind volunteer activity. Linus, by successfully positioning himself as the gatekeeper of a project in which the development is mostly done by others, and nurturing interest in the project until it became self-sustaining, has shown an acute grasp of Kropotkin’s “principle of shared understanding”. This quasi-economic view of the Linux world enables us to see how that understanding is applied. We may view Linus’s method as a way to create an efficient market in “egoboo” — to connect the selfishness of individual hackers as firmly as possible to difficult ends that can only be achieved by sustained cooperation. With the fetchmail project I have shown (albeit on a smaller scale) that his methods can be duplicated with good results. Perhaps I have even done it a bit more consciously and systematically than he. Many people (especially those who politically distrust free markets) would expect a culture of self-directed egoists to be fragmented, territorial, wasteful, secretive, and hostile. But this expectation is clearly falsified by (to give just one example) the stunning variety, quality, and depth of Linux documentation. It is a hallowed given that programmers hate documenting; how is it, then, that Linux hackers generate so much documentation? Evidently Linux’s free market in egoboo works better to produce virtuous, other-directed behavior than the massively-funded documentation shops of commercial software producers. Both the fetchmail and Linux kernel projects show that by properly rewarding the egos of many other hackers, a strong developer/coordinator can use the Internet to capture the benefits of having lots of co-developers without having a project collapse into a chaotic mess. So to Brooks’s Law I counter-propose the following: Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

Life is like an open-source software- freely given, but its development depends on you.

Life is like an open-source software- freely given, but its development depends on you.

Life is like an open-source software- freely given, but its development depends on you.

Like most people, developers like to win, too, but the game is different. If you’re wondering why it’s hard to recruit and retain great developers—the kind that Facebook, Amazon, and Google employ—start by understanding what motivates developers.

Developers are just people, replete with ambitions to learn and grow, motivations to do their best work, and a full range of skills they want to exercise. In companies where this is understood and respected, and where developers are given a seat at the table, they’ll be engaged, active company builders with you.

Knowing that customers and your coworkers depend on you, and that you’re changing the direction of your organization and those around you, is a powerful motivator. In fact, the more people who are touched by your work, oftentimes the greater the purpose. And the amazing thing about software is the scale. Writing code that will be used by millions or even billions of people is powerful. Very few professions share the same sense of scale or impact. That’s why developers are particularly motivated by purpose.

We pay higher than most similar companies in base pay, which is guaranteed and not subject to some management fad or poorly set goals. And we tend to give a little more stock equity as well, to compensate employees for the lack of bonus—with the side benefit of focusing employees on long-term versus short-term objectives. My belief has always been to pay people well, so they feel it’s fair, but don’t cloud things by believing that compensation is the great motivator, especially for creative roles.

With a strong customer, a clear mission, and metrics of success, the team is well set up to execute, driven by an intrinsic motivation. These three things are not invented by executives in the boardroom—they are created by the team themselves. That helps keep it personal.

You can agree to this whole RAPID® process, but if there’s always a manager who can just veto the whole thing, the person who in theory has the decision really doesn’t. That’s the opposite of empowering a single-threaded leader. You say they have the authority to make decisions, but if you second-guess or, worse, veto those decisions, you’re actually just giving them agency in name, not in actions. They’ll be afraid to make decisions, and will delegate most things upward to you. I think of this as the great destroyer of intrinsic motivation.

When writing a commit message, ask yourself whether developers will need to use that information in the future. If so, then document this information in the code. An example is a commit message describing a subtle problem that motivated a code change. If this isn’t documented in the code, then a developer might come along later and undo the change without realizing that they have re-created a bug. If you want to include a copy of this information in the commit message as well, that’s fine, but the most important thing is to get it in the code. This illustrates the principle of placing documentation in the place where developers are most likely to see it; the commit log is rarely that place.

In hindu tradition, we know the science of making your brain grasp the whole cosmos, the whole cosmic happening.When I was developing the software for sarvajnatva (means the power to ‘know everything’), successfully I have also made many of my gurukul balasants manifest this power for a particular period of training.

Company leaders who build industry-changing software products seem to do three things well. First, they understand why software developers matter more than ever. Second, they understand developers and know how to motivate them. And third, they invest in their developers’ success.