Compare/contrast this with yesterday's valve/abash link...

one of the most powerful "come work here" posts I've ever read

summary of an article; one of the best suggestions: "2. Do not expect and do not support the notion that email should be a real time activity."

"Duck programming also exposes projects to “Naked Risk,” the possibility that bad things will happen without safeguards to prevent it or processes for recovering from disaster. Duck programming can be seductive to development teams because it pushes a lot of project risk away from the project team and onto the shoulders of the users. If something goes drastically wrong, the response from the team will be a shrug and the cryptic notation PEBKAC.3 The system “works as designed,” thus any problem is the fault of the users for misusing it."

"I'm starting to believe that the Managerial class fears programmers the way that Bronze Age nomads feared blacksmiths - programmers wield mystic powers that shape reality, and are best done away with when you are done with them."

better than the usual whiny "we're so awesome, people just don't understand us"

great metaphor to show just how many assumptions are baked into such a seemingly simple task as "hang this picture"

"A healthy product company is, confusingly, one at odds with itself. There is a healthy part which is attempting to normalize and to create predictability, and there needs to be another part that is tasked with building something new that is going to disrupt and eventually destroy that normality."

I'm a fanboy of rands

"I am looking for what powerful questions you use in your analysis process so we can create a list ... Here are some examples: 'what is the earliest point you can know whether the system has any value to you?', 'If I turned off the server tomorrow who would be the first person to notice and why?'..."

'“Individuals and interactions over process and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.” That's the entirety of the Agile Manifesto, by the way. Seems simple, doesn't it? Yet there are flotillas of books and courses with detailed instructions and steps for "doing" Agile, as if it were a thing with specific rules and regulations.'

'One of the leading causes of sky falling situations is distributed ownership, and as a strategy distributed ownership seems very humane. We’re going to put the right people on the right problems....A sky falling situation exists not because of a single failure on one team. It’s a collection of multiple large and small mistakes on many teams that snowballs into an unexpected worse case scenario. Teams of people succeed and fail at scale. A likely major contribution to your current disaster is the fact that multiple well meaning and fully informed people looked at an emergent disaster and thought, “Well, someone who is not me is going to handle this, right?”'

reading Moneyball now and this sentence illustrates why, for Lewis, Billy Beane's failure as a ballplayer was so poignant -- what if he'd had a Coach Fitz? What might he have been? "He was teaching us something far more important: how to cope with the two greatest enemies of a well-lived life, fear and failure. To make the lesson stick, he made sure we encountered enough of both."

understanding this and following its immediate web could probably suck up a month or two of serious time: "Conklin identifies the following as defining characteristics of wicked problems: 1. The problem is not understood until after the formulation of a solution. 2. Wicked problems have no stopping rule. 3. Solutions to wicked problems are not right or wrong. 4. Every wicked problem is essentially novel and unique. 5. Every solution to a wicked problem is a 'one shot operation.' 6. Wicked problems have no given alternative solutions."

"The CTO, say Hoffman and Cantrill, is outward facing and should be extroverted enough to enjoy traveling and meeting customers. In general, the CTO will also be the one explaining the company vision to press and the rest of the world. The VPoE, on the other hand, should be an engineer that the team feels comfortable talking to and looking to for advice. They'll be responsible for building the team and take responsibility for distilling the company vision into products and making sure they ship."

slides from the presentation I noted here: http://www.cwinters.com/blog/2012/01/06/pittsburgh_ruby_software_process.html

This is going to be in my "most frequently forwarded links to answer a common question"

great article (June 2007), but this was a classic comment that in hindsight doesn't hold up so well... "Ford survived the Edsel; Apple survived the Newton (and will survive the iPhone, I bet). Gigli didn't sink the studio; they just went and made another movie, fast."

another one that you can't believe is true: "Stephan was their source control. The developers had a crummy Visual Source Safe install configured, which let them have some rudimentary collaboration, but nothing in there "counted". The canonical version was in Stephan's private SVN. When the developers finished a task, they gave Stephan the files. He would compare the changes, manually, line-by-line. If he liked the code, he checked it in. If he didn't like the code, the threw the file away. Sometimes, he might even tell the developer that he had done so."

this is, I think, the heart of the conflict between google people and apple people: "Recall the mathematician and the lamppost. You can be super efficient and very comprehensive but still be looking in the wrong place. It’s common to remark “the plural of anecdote is not data”, but similarily you can’t mistake precision with value. Not everything that can be counted counts, not everything that counts can be counted. This is especially true for start-ups."

"Building a team where everyone is capable of managing their own time is tricky. Getting to the point where managers trust their team enough not to grimace and go asking for updates every time a game of pool starts is very difficult. And you can’t order it online. Unless you have the right culture you’ll just end up with a pool table covered in dust, and copies of EA games from 2007. How’s that for a morale boost?"

"And this is the essential broader point--as a programmer you must have a series of wins, every single day. It is the Deus Ex Machina of hacker success. It is what makes you eager for the next feature, and the next after that. And a large team is poison to small wins. The nature of large teams is such that even when you do have wins, they come after long, tiresome and disproportionately many hurdles. And this takes all the wind out of them. Often when I shipped a feature it felt more like relief than euphoria."

"Number 6: Vader managed risk and expectations...pre-emptively. Remember that time when Darth Vader went to Cloud City, bought off the management, then lured Han, Leia, and Chewbacca into a trap? Genius. The amount of planning and forethought that went in to that little exercise must have been epic."

My favorite: "10. Whenever you start thinking “this is a lot more complicated than I originally thought”, you should immediately stop and find a sounding board. You are probably either wrong or overthinking things, and an external brain will see it much faster than you."

'It turned out that no one really understood how the entire system worked, and that issues at the boundaries of the specialties were causing many of the problems. The way that they had scaled up their organization was to specialize, but that specialization caused them to lose an end to end view of the system. Their organization of their people had led to some of the problems they were experiencing, and was impeding their ability to solve the problems.   The quote that I most remember was "specialization is an industrial age notion and needs to be discounted in spaces where we operate at the boundary of the known versus unknown".'

this is most welcome, but I'd think that the security concerns (real and feared) would squash this at most places.

"Especially if you are an engineer, your success comes through creative problem solving and unique insights into the technical problems that face your company. And as you move from an individual contributor to a team lead, those continue to serve you well. If you are leading a team of 5-10 people, you will continue to be successful by being the brilliant problem solver although, the issues with this will begin to show, especially if you suffer from insecurities or have natural control issues....The problem is that leadership isn't about being the person with the answers, it's about being the person with the questions. You have to shift your mindset from answering questions to asking them, even when faced with questions."

"Software has become like body language in the way it reveals your inner personality to a patient observer. Your body language always tells the truth, even when you are trying to hide an ugly secret, and it will give you away every time. You simply can’t create likable software if you are a dysfunctional company."

nice list, both technical and social

"The first couple of go rounds, there was dead silence. No questions—just head nodding and a couple of blank stares. After some probing, we realized that people needed to feel comfortable speaking up, that it didn’t just come naturally. We brainstormed a bunch of different ways to get over this hurdle and here were some experiments that ultimately worked...I thought we would surface creative answers faster. When everyone had a clear understanding of the hard problems, their collective brains were on the table for parallel processing. The best information rarely sat with the senior executives but with the employees that were closest to the product and closest to the customers. And the best answers would often come from the most unlikely of places."

"The second thing is I started noticing my interactions in the hallway. I'm an engineer by background and a bit of an introvert naturally. When I walk between meetings, I think about things. A lot times I'll be looking down my phone or looking down at the floor while I think things through. It's sort of a natural engineer behavior, but it's pretty off-putting if your CEO walks by you and doesn't look up and notice you."

"Any time new management asks you to re-apply for your own job it is a sign of zero professional regard."

(answer: "probably not") Nice overview with lots of people chiming in (though most anonymous); I think too many people try to highlight a single thing that 'killed' a project, but it's almost never that clean, especially for something as large as this

I didn't know about this one -- '"Enhanced JMX Agent and MBeans" is a recent addition to the schedule. Ported from JRockit, it is an implementation-specific enhanced JMX management agent which is intended to make it easier to connect to the platform MBean server through firewalls, together with a richer set of MBeans which expose additional information about the internal operation of the VM.'

"Good overview of what "engineering" means and how it's changed, gently moving you toward a conclusion that we're shooting ourselves in the foot by trying to replicate the processes of other engineering disciplines."

"3. Human Resources... What better way to let people know that they’re expendable commodities than calling them 'resources'? Indeed, the entire concept of HR is designed to make the process of dealing with real live people as bloodless as dealing with electricity or shipments of iron ore."

interesting ideas and I agree with a lot of it; but like a lot of stuff out of 37signals I feel it's heavily biased toward people like them; this is not a bad thing, but I'm not sure their experiences can be extrapolated to the business world at large

"Homer: [to staff] Are you guys working?
Man 1: Yes, sir, Mr. Simpson.
Homer: Could you, um... work any harder than this?
Man 2: Sure thing, boss.
[they do]
Homer: Hey, call me Homer."

"But by not paying an annual bonus, it's also fostering the sort of environment that doesn't encourage outsized risk-taking by employees doing whatever they can to meet their annual goals. That hardly means the company doesn't wave any sticks: Netflix's zero tolerance for mediocrity means employees are incentivized to keep their jobs at a company that pays them above-market salaries and treats them like the professionals they are."

'''''How did this “best practices” thing get to be such a common meme? Because “best practices” mean, essentially, that the questioner doesn’t want to have to think. And it’s a seductive premise—if I just push the right buttons, type the right keywords, call the right methods and/or use the right classes, I can get something that “just works” without having to think about all those nasty little details that seem to trip people up: performance, scalability, security, blah blah blah....Here’s the dirty little secret of our industry: Software development is hard.'''''

"The “big brother” style of project tracking is especially bad when the “pointy haired boss” type of managers pick up on it. Suddenly, the team is being nagged to start entering more and more granular estimates and updating dates in tickets. For a boss who’s nervous about delivering something, it seems like the right thing to do is to start nagging programmers about every little task that’s entered into the system, or chasing down anyone who’s got a task assigned without a due date."

"Even worse, agile wasn't really helping me ship higher quality software. We were using it to get features to market faster, and that was working well. But we were cutting corners in the development methodology as well as in the code, in the name of increased speed. But because we had to spend more and more time fixing things, we started slowing down, even as we tried to speed up."

"What are the consequences of this more detailed spec? For one, it takes a lot longer to create, meaning that the projects themselves get larger in order to rationalize the increased investment in planning. Second, the extra detail obscures the artists’ original intent in specifying the feature, so the engineers are even more likely to miss the big picture and build the wrong things. And lastly, it removes the engineering team’s ability to find breakthrough solutions that might deliver most of the value at a fraction of the cost. They can’t use any discretion for fear of breaking the spec’s contract, even if the changes would probably go unnoticed or even be in the company’s best interests. The lack of trust (and the procedure of the Waterfall methodology) makes it very difficult to ask for clarification or changes in the spec while the implementation is underway."

"The notion that you’re trying to control the process and prevent error screws things up. We all know the saying it’s better to ask for forgiveness than permission. And everyone knows that, but I Think there is a corollary: if everyone is trying to prevent error, it screws things up. It’s better to fix problems than to prevent them. And the natural tendency for managers is to try and prevent error and over plan things."

"The chart aims to visually communicate a snapshot of progress made in a project that is composed of several smaller projects. It doesn’t attempt to convey informations about timelines, dependencies, or resource allocation, though some of this information can be introduced through the use of colour."

on the benefits of considering operations early, among other things

"We've been told the wrong story so many times we believe it: "the reason for a company is profit." That's like saying the reason we're alive is to eat. Management theory is convinced that it is a science, therefore any improvements must have happened because of scientific knob-twiddling by management. "Drive" shows that improvements happen despite things that management does, that our desire for fulfillment is so strong that we can achieve things in the face of the roadblocks that management places. Consider a skunkworks project, which must be hidden because normal management would not allow it to happen. Or stories of teams that are great within a failing company; team members stay because they are fulfilled by the team despite the catastrophic actions of the management surrounding the team. "

"I discovered that people watched every action to see if it supported undermined our vision. They wanted to see if I practiced what I preached. From the outset, I did simple things to demonstrate my sincerity. I made a sign for my desk that said THE QUESTION IS THE ANSWER, and when people came to me with questions, I asked myself if they were questions I should answer. Invariably they weren't. Invariably people were asking me to make decisions for them. Instead of giving answers, I turned the tables and asked the questions myself, trying to make them repossess their own problems. Owning problems was an important part of the end state I'd envisioned. I wasn't about to let people give theirs to me."

"Again, I’m being an alarmist and I’m exaggerating, but I believe you cannot effectively (and don’t want to) remove yourself from what you do to make a well-informed decision outside of your circle. Think of it like this: is Ryan the customer or does he have direct access to the customer? If the features are for engineers, there’s a solid argument that he could make decisions for both the bits and the features, but if the product or features aren’t targeted for engineers, why do we believe Ryan can make informed decisions about them?"

common commands among rpm/yum and apt-get/dpkg

nice overview, also good for the links it provides (Spolsky, Yegge, MarcA, others)

"I’ve landed BAB in three different teams now and in each case, the amount of trash talking that showed up once players became comfortable with the game was impressive. This is a function of my personality, but it’s also a byproduct of any healthy competition amongst bright people. It’s also a sign of a healthy team. I’ll explain. Trash talking is improvisational critical thinking — it’s the art of building comedy in the moment with only the immediate materials provided. As I’m looking for candidates for my next BAB game, I’m looking for two things: who will be able to talk trash and who needs to receive it?"

"Business needs cause leaders to override the suggestions or opinions of the technical staff. Today's harsh business environment requires that business leaders push their organizations continually beyond their old boundaries, and sometimes this means that a leader has to tell their staff to "damn the torpedoes" and stretch further than they are comfortable. Unfortunately, a non-technical leader has no personal ability to gauge the actual risk profile of overriding technical suggestions (i.e. shrewdly exceeding old limits in certain special situations) and is then prone to eventually overriding technical advice which should not be overridden."

"Hence, your operating efficiency, and thus the number of people you need to hire, and therefore your costs, are directly impacted by the ingenuity of your internal tools. This means that your tools teams should not be a back-office, after-thought function staffed with second-string players. Your most talented engineers should be working on your tools, and your culture must reflect this priority. Writing great tools and continuing to improve and replace them is more important than the next shiny feature."

"At Facebook, there was a cultural resistance to process, to the point where the pattern around introducing process typically went "new process is reluctantly introduced only right before the point where things tip into chaos." Push this point as far as humanly possible, and then some, because what you receive in return is high organizational speed. If your organization has less process than another one of equivalent size, you will innovate and execute faster, taking ideas from conception to market more rapidly. Managers may need to psychologically contend with more chaos than they are comfortable with, but there is a huge difference between chaos that makes one uncomfortable and chaos that actually threatens the business. Stepping as close to the latter as possible confers one of the greatest advantages in the technology business: execution speed."

nice set of slides that has at their root the story of continuous deployment, as they put it: "lowering the risk of change through tools and culture"

"More generally, owners of a project or a codebase have very strong personal incentives to make their users happy, be those incentives financial or purely professional. As a result, for owners efficiency and reduced costs are musts, not simply desirable attributes. Caretakers generally have less urgent objectives. ... Owners and caretakers are present in enterprises and startups. I've worked with owners of very large enterprises—companies owned by a few individuals as opposed to many shareholders—that insisted on very lean development practices; and also with enterprises where decisions were made by caretakers who had no personal financial or urgent professional stake in the process. But I've seen startups, too, where, although employees had a heavy incentive to make the business successful, the ready availability of venture money made frugality a somewhat remote concept."

nice definition: "Traditionally, program managers say "What" and "Why," project managers say "When," and development managers say "How" (which encompasses "Who"). I guess facility managers used to say "Where," but that's stretching things..."

'Two hires I thought we had absolutely no chance of hiring. Both on the team in a matter of months. Your question is, “What’s her secret?” and the answer is dangerously simple - deliberate, consistently expressed and reinforced want.'

Tim Bray on how enterprise IT needs to change, and should emulate web success stories wrt requirements, small teams, etc

+100; get rid of the things that hurt so you can do them again and again, even when you don't expect

"The team player has come to be a euphemism for such a slow and steady worker - predictable and absolutely devoid of hidden reserves & surprises. Someone who would rather move with the team rather than run ahead and look back at others. To make no exceptions and just keep on working, despite lack of motivation or support from above is the clinching quality of the newly defined team player. "

"The biggest danger with getting worked up over the small screw-ups? Making people cautious. If your employees are afraid to break things, they’re going to stick to what they know. No one benefits from this - they don’t grow and you don’t get the best out of them."

make sure the people who create stuff feel the pain of having to maintain it

follow-up on netflix 'culture' slides

slides on Netflix values, how they view employees, and what they optimize for; who *wouldn't* want to work for a place like this? "Responsible People Thrive on Freedom, and are Worthy of Freedom"

"Most executives, especially in startups, don't have the courage to hold their teams to a high standard for new products or features. Just because something looks pretty, or feels like a good idea, or has a lot of sunk cost in it, does not mean it should be pursued. Not even if it's generating revenue. The only efforts a new product team should be expending are those that lead to validated learning about customers."

"As creators and builders, we developers are driven by the desire to produce something which makes us proud.  When robbed of this feeling, for whatever reason, it hurts more than we may even want to recognize."

"When Jordan in Marketing lays down an energetic thirty minutes of incomprehensible marketing buzz-speak, I take a deep breath and attempt to hear his enthusiasm rather than his seemingly meaningless words. I remind myself of the time I walked to his office and threw down twenty minutes of arcane engineering reality and he gave me the benefit of the doubt. He clarified and we found a comfortable place to communicate."

"There's a certain hubris associated with the notion that you can have a complete specification for something. You almost certainly can't. You almost certainly don't know your true needs ahead of rollout."

summarizing four levels of knowledge of lots of different programming and software development topics

includes widgets for tracking (desktop and in-browser; not sure about android...)

on interviews, finding the right people, cutting short diminishing return meetings, and the importance of failing

story planning, velocity tracking, manipulating stories in iteration

"An obsessive meeting schedule is an investment in the boring, but by defining a specific place for the boring to exist, you’re allowing every other moment to have creative potential. You’re encouraging the random and random is how you’re going to win. Random is how you’re going to discover a path through a problem that one else has found and that starts with breathing deeply."