5 ms·
Most developers work on projects where the success or failure of the project is determined by stakeholder interactions. There is at least an order of magnitude
by JamesBarney 8y ago
Most developers work on projects where the success or failure of the project is determined by stakeholder interactions.
There is at least an order of magnitude difference between the number of products that have failed because someone didn't use the right algorithm versus didn't set expectations appropriately, or built the wrong software.
Communication matters, a lot, so books about communication and structure also matter a lot.
- InGodsName 8y agoWell, the way i am interviewed it always made me feel as if success of the company depends on my blackboard data structure and algorithm skill.
- sinuhe69 8y agoYeah, you said yourself that’s “in a interview only”. I agree that many modern interview techniques are stupid. Perhaps they think the leaders know how-to communicate well already or perhaps because soft-skills are notoriously hard to assess. But in my experience, algorithms and data structures questions can only reveal very little about the potential of the candidate. A lot of truly important skills can only assess through interaction with experienced human evaluators.
- seanmcdirmid 8y agoIsn't that really selection bias though? Projects with bad management simply don't make it. Those with bad algorithms make it but with lots of accrued technical debt. Reading a soft skills book is like taking mandatory anti-corruption training at work. It is boring because its obvious, but unfortunately some people still need it.
- tracker1 8y agoIt depends... a given software application that only has a handful of users on a dedicated server can totally survive a less than perfect implementation. Right now I'm working on an application that will be deployed to multiple independent customer sites. That same application will never likely see more than 1k users on it at the same time (mostly about 20). How much effort should be made towards optimization, or custom data stores? Or just use {insert favorite sql dbms}?
- seanmcdirmid 8y agoAgain, bad software project management can over engineer as much as they can under engineer.
- beat 8y agoSoft skills aren't as obvious as they seem. That's why we need books about them.
- bad_user 8y agoThis is moving the goalposts. Due to rampant ageism, most people in this field are afraid of becoming irrelevant in their forties due to the rapid evolution of the industry, therefore staying relevant is of concern. But if we are going to talk about what drives the success and failure of projects, the "stakeholder interactions" are only one part of the problem. I've worked with 3 startups already and have heard stories from many others ... For startups that die, usually the blame lies with not finding the "product/market fit" however the reality is that startups only have a small window of time in which they can present their product and win customers and if your MVP has bugs or is underfeatured, it can kill your business, irregardless of how well connected you are to your stakeholders and your clients. Going further than startups, in software companies developers do have to talk with stakeholders in order to understand the requirements. Asking the right questions however is a matter of technical skill and no discipline will teach you how to better dissect a problem in smaller problems than math and a scientist will always be better at asking questions than non-technical folks ;-)
- beat 8y agoI don't know how old you are, but I'm in my 50s, so I have some perspective on this. I don't worry about becoming irrelevant at all. But that is as much due to the "soft skills" that you dismiss as the hard skills, maybe even more so. I've been through enough projects, from tremendous successes to total disasters, that I can see large-scale patterns. And those are never about tiny algorithmic details. They're only sometimes about technology. The people my age that suffer career losses and anxiety usually do so because they stayed in one place too long. Getting laid off or fired after 10-15 years (or longer) in one place can be disastrous. Part of it is that they no longer have practical interview skills, or even understand the current trends in recruiting and hiring. But a lot of it is because their skill set becomes company-specific, deeply tied to the business of their long-time employer. They might be (and often are) fine programmers or analysts, but their resume doesn't reflect that. As for startups... if you think an initial product (MVP) having bugs or lacking features is the reason startups die, you're not paying much attention. I would go far in the other direction! A company that doesn't release a buggy, incomplete product will die. That's because startups are a race against the clock. They need to show results (usually measured in sales) quickly enough to not run out of money, or at least get them to another round of investment to keep them going. The longer the time to market, the harder that is. And customer feedback is the best way to find the shortcomings in your product. The reason anyone buys from a startup is desperation. That startup needs to be offering something that cannot be obtained from an existing, stable market player. This is especially true in B2B, where businesses are actually risking something by committing to a startup, other than their free time. A startup needs to find such a big pain point, such a big market gap, that customers will put up with a buggy, incomplete app, and pay for the privilege. That is the secret to a successful startup - certainly not polishing the turd til it glows. (Read Crossing the Chasm for great depth on this, if you don't mind a bunch of boring soft-skill reading.)