|
raddevus wrote: We've promoted them to positions in management.
Ahhh, the Peter Principle. I find it holds true more often than not.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
David Crow wrote: Ahhh, the Peter Principle. I find it holds true more often than not.
Yes, unfortunately, in these enlightened times the darkness still prevails. 
|
|
|
|
|
Another reason I miss my cube, nap time.
|
|
|
|
|
(being awakened by noise) : "Can all you people keep that Agile noise down over there! Do you really have to iterate so much?"
|
|
|
|
|
Promoted to their level of incompetence often because they have been to the right schools.
|
|
|
|
|
Yeah, it's very difficult to deal with managers who've never done tech work themselves. Much better if a manager has been in the trenches too.
|
|
|
|
|
raddevus wrote: Contrast that to a project where you stand the chance to make a $1 million.
Hypothetically (with a big H!) if I were to work at one company for 30 years...
...there are actually quite a few people at the company where I work that have worked 30+ years for that company, though the only devs that are 30-yearers are COBOL devs and they're retiring left and right, haha....
and my average salary over those 30 years, say, $90,000 / yr....
I would earn $2.7M, pre-tax, etc.
I propose that one should look at employment as "the big project." But then again, this is all so totally hypothetical because most devs never stick around for 30 years. If I were working for NASA or SpaceX, or even Apple, Microsoft, IBM, Google, or Amazon, maybe that would still be possible.
raddevus wrote: There is a lot of separation on software dev projects.
I would use the word "disconnect." Particularly between management and their team. 
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Marc Clifton wrote: I propose that one should look at employment as "the big project."
That's a very good point. Very nice re-framing of the idea.
However, I want the $2.7 all at once. It's not near as fun getting it over time.
Marc Clifton wrote: I would use the word "disconnect."
That is a better term for the situation. It is a disconnect and it happens a lot.
|
|
|
|
|
raddevus wrote: I want the $2.7 all at once.
Chances are that if your product is making you that much money, then you are also having people on your payroll, and company overhead, etc. At the end of the day you are making 90K a year.
Very few people have a software product that earns good profits every year, and they are the only one on the project. Notch with Minecraft is a great example, but even after a couple of years he had to hire help.
|
|
|
|
|
Slacker007 wrote: but even after a couple of years he had to hire help.
Just send the $$$, not the people.
|
|
|
|
|
raddevus wrote: If You Were Developing a Product With Chance of Making $1,000,000
Contrast that to a project where you stand the chance to make a $1 million.
Aren't those the same? 
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Oh, the one was the header, the other was the sentence following the previous paragraph. 
|
|
|
|
|
raddevus wrote: Scenario-Focused Engineering: A toolbox for innovation and customer-centricity
Could they not have come up with a slightly less-buzzwordy title? Something like:
Scenario-Focused Engineering: A proactive blockchain-orientated power-toolbox for agile dev-ops innovation and running enterprise-level-customer-centricity up the flag-pole to see if it flies blah, blah, blah. Cloud!
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
|
|
|
|
|
PeejayAdams wrote: Could they not have come up with a slightly less-buzzwordy title?
No. because, in the end, it isn't the product...it's the marketing. I mean look at stuff people are paying billions for...facebook, etc.
|
|
|
|
|
I haven't seen that book, but MS was talking about those ideas back in the 1990's
And I've work with that methodology ever since. It works!
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Walt Fair, Jr. wrote: I haven't seen that book, but MS was talking about those ideas back in the 1990's
And I've work with that methodology ever since. It works!
Very cool. And I believe that it would/does actually work.
Those few principles are very, very good and get to the core of what should really happen.
|
|
|
|
|
Buzz word laden hype. I just want to know what the users are trying to accomplish.
Maybe I'm just bitter. 
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
|
When you find out -tell the users.
Socialism is the Axe Body Spray of political ideologies: It never does what it claims to do, but people too young to know better keep buying it anyway. (Glenn Reynolds)
|
|
|
|
|
S Douglas wrote: Buzz word laden hype.
Wow, you really thought those few bullet points were buzz word laden hype?
That's fine. Maybe you have a lot of experience and you know how to get to the point on a project?
That's probably it. I notice that after 25 years of software dev / IT work, projects are so repetitive it can seem like everything is hype.
|
|
|
|
|
So many devs are not business focused.
Just look at the complaining we had here recently about being asked to dumb down their code.
Had a case recently where a dev was complaining about being taken off a task because it had been given to him in order to make senior engineer.
My response was 'take care of the product and the career takes care of itself'. ie, focus on the product and nothing else. Not how cood your C++ is, how many fancy, nerdy, features of a language you can use, but instead on how quickly you can push good product out the door.
|
|
|
|
|
Munchies_Matt wrote: So many devs are not business focused.
That is a very true sentence. Devs often become way too focused on tech and tech is meaningless by itself.
Munchies_Matt wrote: 'take care of the product and the career takes care of itself'
That's a good mantra to work by.
|
|
|
|
|
My company once offered me a huge cash bonus, per delivered project, as an incentive to release products faster.
I refused, because I go to work to play around, get smarter, and make the clients happy.
Just pointing out that your monetary motivation might not works as well as you'd expect.
Also, there's something missing in your list:
*** every iteration you reduce the amount of code you need to maintain
If you work towards the simplest solution that is still economically viable, you'll stumble upon the core values of your sub-domain, sooner rather than later.
Once you find those, you can re-align your business practices and reduce the amount of people you need.
Of course, instead of firing anyone, you should branch out instead to a related sub-domain.
Diversify whenever you have nothing to loose, so you don't get blind-sighted by rising oligopolies in your sub-domain.
|
|
|
|
|
KBZX5000 wrote: Just pointing out that your monetary motivation might not works as well as you'd expect.
I know what you mean. It's really more about _ownership_ than it is money. I've developed my own projects that have never made any money but I'm 100% invested in them. Money was the easiest (and maybe funniest) way to explain it.
KBZX5000 wrote: *** every iteration you reduce the amount of code you need to maintain
I totally agree with that. Sometimes I say, "the best solution may include no code at all" and people think that is strange for a developer, but code is not a panacea -- and as you know it often causes more problems.
Reducing code is always a great idea.
|
|
|
|
|
There is separation on software projects because no project is the primary focus of most of the people involved in it. Project owners have their management or other jobs to do, users have their main jobs to do, even the UX and coders have other projects they are working on. You can't get all these people in the same room at the same time all day every day. But if you can get them together in the same room at the same time for an hour or two every day, or twice a week or so, I think the project would be much more likely to succeed.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Key to success is QUALIFIED developers (not an indian "seniors" with 1 year of experience) + FULL ATTENTION TO FEEDBACK. Last one never ever considered seriously in every company. Every "top" thinks "he rules" and just f** any opinion he doesn't like. FIRE HIM, he works AGAINST the company!
Software is not made for developers - it made for USERS. But exactly users are who listened the last! WTF??
If your manager/support/dev doesn't read every single feedback - he lose important info. If he cannot understand what user needs, he is clown occupying wrong position. Every feedback should produce idea or feature, there is no "empty feedback"!
This is why MS rolling down - everybody there thinks they are smarter than users. And they think they can round the Earth in their direction. MS will be destroyed in 5 years, they are not players anymore.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
