https://www.amazon.com/Tom-Demarco/dp/0932633439/?nodl=1&dpl...
[1] https://www.amazon.com/Peopleware-Productive-Projects-Tom-De...
_Peopleware_ by Tom DeMarco and Timothy Lister is the best management resource I've encountered.
https://www.amazon.com/Peopleware-Productive-Projects-Tom-De...
It also helped to keep careful track of things I really valued (and hated) about people I've worked for.
Just one example:
Depending on team size and culture it can concerning if your manager schedules a 1:1 meeting with you out of the blue and outside of your normal cadence. I had a manager that did this, on a Friday, with the meeting scheduled for Monday. Worrying about it would have bugged me over the weekend. Not a ton, but some. He followed the invite up with a Slack (team chat app) message explaining what the meeting was and what he wanted to talk about, turns out it was nothing to worry about. Him taking the time to clarify made a difference in my morale and it stuck with me.
Super small thing, but it matters.
"The most surprising part of the 1985 Jeffery-Lawrence study appeared at the very end, when they investigated the productivity of 24 projects for which no estimates were prepared at all. These projects far outperformed all the others (see Table 5-3)."
Table 5-3 Productivity by Estimation Approach (Full Result) ----------------------------------------------------------------------- Effort Estimate Prepared by Average Productivity Number of Projects ----------------------------------------------------------------------- Programmer alone 8.0 19 Supervisor alone 6.6 23 Promgrammer & supervisor 7.8 16 System analyst 9.5 21 (no estimate) 12.0 24 1. http://startupclass.samaltman.com/courses/lec07/ 2. https://www.amazon.com/Peopleware-Productive-Projects-Teams-...
Pick one (or more):
* they don't know the alternative
* they're afraid to speak up and sound un-cool
* they don't realize it's actually killing their ability to focus
* they do so privately and are ignored by the higher ups
Audio-visual distractions have proven to be detrimental to focused, "intellectual", work. Not by an article on Medium, but by actual research[1]. Time[2] and time again[3] and again[4], ad infinitum.
Open office is the anti-vaxx of today's tech world, where all known data is ignored in favor of superstition.
[1] https://www.amazon.com/Peopleware-Productive-Projects-Second...
[2] http://www.news.com.au/open-plan-offices-make-you-sick/story...
[3] http://online.rivier.edu/open-office-layout-and-employee-pro...
[4] http://www.sciencedirect.com/science/article/pii/S0272494413...
In my case, I'd like him to read Fred Brooks' "The Mythical Man-Month", to make him understand how a programming system costs a lot more than a simple module.
Summary: http://javatroopers.com/Mythical_Man_Month.html
In second place, I'd place "Peopleware", so he'd understand the importance of communications, and how the current office arrangement is losing the company a lot of money:
Summary: http://javatroopers.com/Peopleware.html
Amazon link to both:
http://www.amazon.com/The-Mythical-Man-Month-Engineering-Ann...
http://www.amazon.com/Peopleware-Productive-Projects-Second-...
The guy coding a little slower but who customer success always talks to about problems. Great, he’s enabling communication between teams.
The girl who cleans up behind the “flash” programmer whose prototypes are awesome but doesn’t quite finish.[1] Great, she’s creating production code to be maintained by a team.
The list goes on. People provide value in ways that are not always apparent. I think Peopleware talks a bit about this although I may be mistaken, about the one team member who didn’t seem to fill a role but made everyone happy.[2] If the team wins everyone wins (hopefully in a good org).
The most exceptional teams have people filling roles. Every role is important and provides value. It’s why teams with a ton of exceptional people often implode, because they are all exceptional at only one thing and no one is filling the other roles. So all the members may appear exceptional, but the team is weak. It's a value systems problem.
[1] http://firstround.com/review/how-to-spot-and-magnify-the-pow...
[2] http://www.amazon.com/Peopleware-Productive-Projects-Second-...
http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...
http://www.amazon.com/Peopleware-Productive-Projects-Second-...
"The art of multiprocessor programming", excellent book on parallel programming theory with code explanations: http://www.amazon.com/gp/product/0123705916?ie=UTF8&tag=nirs...
> Not every programmer in the world wants to work in a private office. In fact quite a few would tell you unequivocally that they prefer the camaradarie and easy information sharing of an open space.
> Don't fall for it. They also want M&Ms for breakfast and a pony. Open space is fun but not productive.
http://www.joelonsoftware.com/items/2006/07/30.html
See also: http://www.joelonsoftware.com/articles/FieldGuidetoDeveloper...
But most developers work better in offices with doors that shut (at least according to what I remember of Peopleware [http://www.amazon.com/Peopleware-Productive-Projects-Second-...], though that was published before IM was everywhere).
So I think acknowledging that you work better with quiet, and framing it as 'I want to be as effective as I can', is fine.
It can even open up a discussion on true effectiveness--if I am writing tons of great code because it is quiet, but you could have saved me 8 hours of code writing because of a library you know about or wrote, am I as effective as I could be (no). This is the quiet end of the spectrum.
The loud end is the bullpen with no headphones, where it can be very difficult to think.
When you're done, I'd love to hear your thoughts on PMs, and why we're still making the same mistakes we made, and wrote books about, 30 years ago.
[1] http://www.amazon.com/dp/0932633439/
[2] http://hbr.org/product/new-new-product-development-game/an/8...
http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...
Peopleware: Productive Projects & Teams http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...
Delivering Happiness: A Path to Profits, Passion, and Purpose http://www.amazon.com/Delivering-Happiness-Profits-Passion-P...
Rapid Development: Taming Wild Software Schedules http://www.amazon.com/dp/1556159005/?tag=stackoverfl08-20
The Five Dysfunctions of a Team: A Leadership Fable http://www.amazon.com/Five-Dysfunctions-Team-Leadership-Fabl...
Fundamentally, cultivating a healthy team culture is the most important role you can play. Foster open, transparent communication, and avoid falling into the trap of micromanagement. Keep things happy, keep it real. All the best!
I've had the same experience. A couple of years ago we decided to implement a rather large part of a project in JRuby (the other part was written in Java), because it seemed to be the right tool for the job: a scripting language that can interoperate with java libraries out of the box.
In retrospect it was a bad decision, because the interpreter error messages were (are?) cryptic (at least compared to what you get with Java) and IDE integration was really, really bad. Cross-language re-factoring was broken and we ended up unit testing almost every line of JRuby code to make sure we didn't introduce regressions when making changes to running systems.
There's a part in Peopleware (http://www.amazon.com/Peopleware-Productive-Projects-Teams-2...) where the authors describe that the choice of programming language has almost no impact on the success of a project. So why add additional risk when there's no proven benefit?
Edit: Also, people always argue that they can get things done much faster in "esoteric" languages, but forget about the time spent on maintenance, bug fixing, explaining code to new colleagues, ...
Inspired: How To Create Products Customers Love (http://www.amazon.com/Inspired-Create-Products-Customers-Lov...) - The best if not only required reading for product management
Peopleware (http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...) - Great read on managing and understanding people as it relates to organizations
Managing Humans (http://www.amazon.com/Managing-Humans-Humorous-Software-Engi...) - Obviously on management, you can read much on this http://randsinrepose.com/, though the book does a great job of consolidating it
It's kind of an old book, but then the principles have remained the same. It also means this book isn't then laced with specific methodologies of the day or what not.
Downside is its a tad expensive on paperback, but reasonable on Kindle:
http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...
Then they put half of each group together in a silent room, and the other half of each group in a different room equipped with earphones and a musical selection. Participants in both rooms were given a Fortran programming problem to work out from specification. To no one's surprise, participants in the two rooms performed about the same in speed and accuracy of programming. As any kid who does his arithmetic homework with the music on knows, the part of the brain required for arithmetic and related logic is unbothered by music—there's another brain center that listens to the music.
The Cornell experiment, however, contained a hidden wildcard. The specification required that an output data stream be formed through a series of manipulations on numbers in the input data stream. For example, participants had to shift each number two digits to the left and then divide by one hundred and so on, perhaps completing a dozen operations in total. Although the specification never said it, the net effect of all the operations was that each output number was necessarily equal to its input number. Some people realized this and others did not. Of those who figured it out, the overwhelming majority came from the quiet room.
Many of the everyday tasks performed by professional workers are done in the serial processing center of the left brain. Music will not interfere particularly with this work, since it's the brain's holistic right side that digests music. But not all of the work is centered in the left brain. There is that occasional breakthrough that makes you say "Ahah!" and steers you toward an ingenious bypass that may save months or years of work. The creative leap involves right-brain function. If the right brain, is busy listening to 1001 Strings on Muzak, the opportunity for a creative leap is lost.
The creativity penalty exacted by the environment is insidious. Since creativity is a sometime thing anyway, we often don't notice when there is less of it. People don't have a quota for creative thoughts. The effect of reduced creativity is cumulative over a long period. The organization is less effective, people grind out the work without a spark of excitement, and the best people leave."-Peopleware[http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...]
http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...
Joel Spolsky mentions that every manager at Microsoft has to read it (I could be wrong on that, but a lot do read it apparently).
Some possibly helpful resources which you may have already seen:
http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...
http://www.joelonsoftware.com/ (right sidebar has a ton of articles)
http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...
Buy this book: http://www.amazon.com/Peopleware-Productive-Projects-Teams-S... and read/skim it. If you don't "get it", accept what it says as Revealed Truth and then if you have any talent for this game you'll understand more and more as you play it.
The Joel Test is also a good thing to pay attention to and follow: http://www.joelonsoftware.com/articles/fog0000000043.html
The biggest issue, which I don't sense the author gets, is "repeatability". Level One companies are entirely dependent on "heroes" (or cowboys, take your pick :-) and their ability to follow their first success is not particularly predictable, except that it's likely to be poor. Look at Lotus, who's first product (the 1-2-3 spreadsheet etc.) was written by a team of 7 or so assembly language wizards for the first IBM-PC and that lost it's ability to develop software after that (1-2-3's mid-life kicker that saved the company (for a while) was an unauthorized project written by two programmer who left the company before the need for it was acknowledged).
I think we realize this less now because we're so much more leveraged and "powerful" today; a small team can do so much more and continue to do that if the company avoids Teamicide (http://www.amazon.com/Peopleware-Productive-Projects-Teams-S... , READ IT!!!) and doesn't have to grow its team (much).
Microsoft, on the other hand, by the 1994 date of this essay was most certainly not a Level One company. I've long said the secret to their success in the period that includes that year was that they retained the ability to write software that basically worked (compare this to all their Windows Office competitors who lost in the transition to Windows 3.x: with the exception of WordPerfect, the others couldn't get past the "crashes too often" stage, and WordPerfect's release was a sad joke. Sure, it didn't crash, but it also would frequently move all your figures and tables to the bottom of your document.)
It's No Accident that Microsoft was run during that period by a seriously good hacker (anyone who can successfully rewrite an assembly BASIC interpreter (without benefit of a computer) during a transcontinental flight earns my respect.)
I too prefer Gerald Wienberg's approach to this, and CMM can obviously be fetishized and at best promises little more than "we can continue write mediocre software", but there's something there that's worthwhile that it's trying to achieve.
http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...
I would paste some quotes but I lost my copy.
https://www.amazon.com/Peopleware-Productive-Projects-Tom-De...