181–190 of 396 posts
2. Obsession with development costs being a capital expenditure (CAPX). All code must be new features.
3. Project deadlines created by management and sales only, always aligned with a fiscal quarter.
4. Projects, not Products.
Earlier quoted context omitted.
That looks on the face of it nice and worthy but it's rather be meaningless because those are not actual goals. Those words are way too loose for that. The other thing about it is it smells like a marketing phrase rather than anything truthful
Why would they be meaningless? You can use this list in any way. For example when you want to increase your product price. This is fine when it is good for the customer (because they will get a better product). But it is not fine when you do it for the shareholders alone. They are also goals because the ultimate goal is to please the customer, then the employee and than the shareholder. I think they are great guideli…
In the consulting company where I work at employees come before customers. Employees are the single most important asset and much harder to replace than customers.
There are a lot of process problems, a lot of productivity issues and lack of strategy, but the cold relationship kills the team's vibrancy and drains the energy, preventing people to do more in a better way.
I've never met a manager that wouldn't rather pay four average people $100/hr to solve a problem that one smart person could solve in half the time for $400/hr. There seems to be some sort of quasi-religious belief in the fundamental averageness of humans; consequently the difference between developer salaries at any company varies by maybe 50%, whereas the productivity varies by at least a full order of magnitude. U…
These 4x (or 10x or whatever outlandish multiple) developers are rare, if they even exist, unless one constrains the scope of their work to a tiny sliver of their particular expertise. Hiring for such micro optimization is inefficient at best, ineffective usually, and counterproductive at worst.
The existence of a 10x developer is a question of what you use as a reference point for your scale.
* creating extra administrative burden around daily things, and trying to commit devs to that
* favour management roles over engineer roles
* ...thus effectively limit technical career: higher positions are non-technical and managerial only
* create two "islands": management and technical, with limited interactions
* treat engineers as easily replaceable parts, keep one or two experienced ones (for extinguishing fires) and forget the rest.
Working for a company building heavy hardware, I see the following happen time and time again: * Reorganizing seemingly for the sake of reorganizing. Result: Every time the new organization has settled somewhat and people know who to interact with to make things flow smoothly, everything is upended and back to square one. * Trying to make our products buzzword compliant without understanding the consequences - we've…
> a man "a person"?
* Zero career direction and zero technical speciality for devs * Underestimation of difficulty whether through cynicism (burn the devs) or cluelessness * Inadequate training and expectation devs can just piggy back learning technology x from scratch whilst writing production software using it * Trying to use one off contracts as a way of building resellable products * Insistence that all devs time must be billable an…
>Insistence that all devs time must be billable That one can hit all areas of ICT real bad when the company is a managed service provider, leading to a 'Chefs kitchen/Plumber's bathroom' where the company provides great outsource ICT services offering to its clients, but runs an absolute shitshow for it's own systems because they're chronically under resourced (you can't bill it, so don't spend time on it). That has…
* Technology decisions in large organizations will often not be made based on technical evaluations or merit. Some other arbitrary thing will influence a decision. You will get stuck with technically inferior product and have to deal, some call this job security.
* If you propose something and it gets floated up the management chain, chances are good that management will not "buy in". Not until they hire consultants to come in at $300-500/hr to spend 6 months or more and come back with the same decision. Possibly using a technology the consultants are pimping out, see point above.
* Buying COTS (customizable off the shelf software) with a 20% yearly maintenance/support fee to do basic IT functions is viewed as being cheaper than hiring software developers to build and maintain it. Even when there are open source solutions.
* Maintaining a list of "approved" vendors. This really narrows your possible solution set. When the vendors know this they will keep increasing fees.
* Offshoring work to save money. Many times this is not really done to save a department money. They will use accounting loop holes to track the offshore work as a 'service' and not labor. It will cost your department more in terms of delivery time but they don't care.
* Decision making by committee. Your job is to make decisions and the dysfunction is so bad that people will not work together. Not in a dramatic way, just passive aggressive, ignorance, etc. Every decision takes forever because they have to confer with multiple peers, go through management hierarchy for some, etc.
Earlier quoted context omitted.
I think I'm 10x in some tasks and 0.1x in others, not sure about everyone else...
I think probably most of us are but the 10x guy is someone who believes themselves to be 10x across the board
Some tough problems that took other skilled developers months they could solve in a couple of days and they could consistently do it across the tech and domain sphere.
I think the issue is people claim to be 10x, if you're claiming to be 10x then most likely you are not, the 10xers I've met have all been very humble.
Short term-ism. It seems to stem from the need to report financially on an annual basis, which means everything gets tied to that - bonuses, sales discounts, hiring, project deadlines. The reality is that many extremely worthwhile things take longer to do than whatever time is left in this financial period and are harmed by trying to shortcut, sometimes irreparably. Tying everything to an arbitrary accounting period often encourages behaviour from management that is counter productive in the longer term. Yes a company has to report, but it doesn't have to treat those end of year numbers like they are the basis for everything.
Distrust. Often management simply do not trust their employees to know better than them. I've seen senior management who haven't got their hands dirty for two decades overruling far more qualified and experienced people on technical and operational decisions inappropriately with disastrous consequences (e.g. a new product suite developed over five years for a 9 figure sum arrives on the market on a legacy platform with far less functionality than what it is attempting to replace). Usually this stems a senior manager assessing risks poorly where they are in unfamiliar territory.
Lack of empathy. I've lost count of the number of initiatives and re-organisations and changes introduced top down style which fail miserably because there is zero engagement from employees. Usually the management have simply forgotten to think about what a change means to them and how it will affect their work. The assumption seems to be if a change makes a business easier for a manager to manage, it must be the right thing - even if that makes the people that do the work less effective. Often there's a drive to make revolutionary changes for the wrong (career enhancing) reasons. Usually it's better to encourage change to happen organically at all levels of the organisation and often it's better to evolve. People are people, if you don't take that into account and empathise you will have a bad time.