|
Slacker007 wrote: I can't possibly see any health benefits in working long hours at a high intensity.
No social life or spare time to indulge your vices?
|
|
|
|
|
I am fairly certain that having no social life and working long hours at high intensity will produce many vices to indulge in. 
|
|
|
|
|
I think there'll be a lot of hitting the road if he's not careful. 
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: I think there'll be a lot of hitting taking the road and saying "screw you" if he's not careful. 
FTFY
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Inspired douche-buggery
Software Zen: delete this;
|
|
|
|
|
Work.............. Life................. Balance............ I do wonder about this "quiet quitting" phenomenon. Apparently people are doing their jobs and just their WHOLE job and then shockingly they are going outside and enjoying life.
Apparently people are then happier with life. I mean who would have thunk of such a thing.
To err is human to really elephant it up you need a computer
|
|
|
|
|
Regular high intensity work, or Special High Intensity Training?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
Why is anyone surprised by this. Look at his other successful companies, Tesla and SpaceX, and you see this same work environment. Boring Company doesn't seem to be as successful and you also don't hear about this type of work environment there.
Had Musk just done this when he took over he wouldn't have had to fire half the staff. They would have quit, saving him 90 days salary for over 3,500 people. A change in work requirements leading people to mass quitting is not one of the triggers in either the US WARN act or its California counterpart, so long as those work requirement changes are consistently applied and for longer than the notification periods required by these two Laws.
|
|
|
|
|
will the birds fly out of the cage ?
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
I've not been on here for a few days, so maybe I missed it. So if this has already run it's course, please ignore.
But, anyway, I'll pitch in with my two lines...
If a manager can only figure out who the good and bad developers are, by counting lines of code written:
He/she shouldn't be a manager.
|
|
|
|
|
Uh, yeah, pretty much everyone here agrees with that.
But that's just the tip of the iceberg.
|
|
|
|
|
Indeed.
I had a coworker who had a negative line count. He refactored an old library and got rid of thousands of lines, while maintaining functionality. That was the best thing that had ever happened to that library, which suddenly became a lot more manageable.
|
|
|
|
|
I had to upgrade an industrial line with a robot.
The program of the robot was around 15k lines of code and over 1200 positions.
When I ended, my program had a bunch more functionality while being more stable and having not even 2k lines and around 350 positions.
The maintenance guy bought me a bottle of wine because I had made his life waaaayyy easier with that changes.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Ah, a manager that can count!
|
|
|
|
|
Oh sweet bliss!
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
I remember reading in Dr. Dobbs about 20/25 years ago that there was a manager who used a tool that would count semicolons to determine number of lines. This information got leaked to some junior programmers who then started writing lines as -
;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
|
|
|
|
And thus is revealed a great problem
No matter what you do to try and leverage a metric out of what we do as software developers, there will ALWAYS be someone who figures out how to game the system.
|
|
|
|
|
Or by counting the number of hours worked.
Had a manager at a previous job whose "best worker" clocked in 60 - 70 hours a week. The problem was this worker took 60 - 70 hours to complete the same amount of work everyone else completed in 30 hours.
"I reject your reality and substitute my own." -- Adam Savage
|
|
|
|
|
Upvote is for the Tag line 
|
|
|
|
|
To be honest, and as a manger...
In the beginning, all we had was "Code" and "Needs".
As Needs were filled, "Code" was created.
But even by the mid-late 1980s NOBODY seriously use LOC of a meaningful amount of work/complexity.
My first job tracked "Change Requests" completed. And for us, that meant from assignment,
to coding, testing, validating, having the customer/client sign-off, modifying the documentation,
having the Operations Staff sign-off and potentially the user Managers sign-off that the documentation
was complete. In some cases, the "Systems and Specifications" Manual was updated, and the Flowcharts,
and other diagrams updated... [There was a pretty big checklist, (Does this Apply: Y/N completed Y/N)]
Given those details. The ABSOLUTE insanity of measuring LOC as EFFORT was terrible.
We simply took to measuring how many CRs (Change Requests) each developer completed. Which, too,
was not fair. Some things were as MINOR as "Bold this text ON this condition". And others were,
change the intrinsic calculation of Insurance Premiums for vehicles over $x and below $y between 0 and 3 yrs old. Then some CRs had like 15 user requests (all related) merged into one.
The point was that measuring SOMETHING gave you an idea.
FWIW, the LEAST productive programmer was the ONLY ONE with a degree, and he had a Masters.
I was 19, and I learned so much from that environment (like there is more to coding than CODE,
and SUNK COSTS apply to fixing a horrible program that should be rewritten)
|
|
|
|
|
During my reign working in the mobile comms industry here in the UK, we had a massive problem with that.
Some faults would always be simpler than others, and we had a daily target of "reported issues" to deal with.
Once the management figured out however that we were only keeping our targets by literally picking off the easy ones, and leaving the hard ones, that practice stopped, and the shift leaders where tasked with giving each team member a cross section from the "in queue" each day, some of which were easy tasks, some of which were hard.
The next big complaint from management was then "why can't folks complete the assigned x tasks per day?"
To those not down on the floor, every task to them was a line on a spread sheet, and every line on the sheet had and arbitrary time assigned to it based on what management thought the issue & resolution was.
|
|
|
|
|
Wow, yeah, I've been in those environments (luckily not for long).
We had a situation where for 2-3 months, I literally had 80% of a 3 person teams productivity.
(One guy was useless), I was pounding UNPAID overtime in. Amazing what an extra GOOD hour adds up to, each week.
Then the owner sat us down, was needing an estimate on man-hours to bring a new business online...
We gave him the number... Like 800 man-days (excluding our current work getting done).
He looked around the table, and and saw 5 people (3 Devs, 2 managers) and said so if we bring in 3 more people, we can have this in 100 days... (as if 100 days was 100 work days, as IF managers were programmers, as IF new developers would be useful...)
I stood up and said. Come to think of it. If you hired 100 people, you could have it in about a week! Problem solved. And I walked out of the meeting. Went back to work.
My manager called me in his office and said "You know that meeting wasn't over?"... "For me, it was!" I replied. That level of AI (Arrogance + Ignorance) should not be tolerated!
==> For the estimates. I usually push back with:
How much is this worth in Developer Hours?
At which number of Hours should we NOT do this?
THEN I ask them what their estimate is (it's useless, but I can usually point out...
Any change to the system requires like 4hrs, just to get it through testing and published, updating docs, scheduling downtime. And that's to change the VERSION #... LOL).
Most of the time, they are just not educated as to how hard it is to do our jobs.
They have no idea what we do.
|
|
|
|
|
"I'm gonna write me a mini-van!" -- Wally
Change Request 1: Implement Feature X.
Change Request 2: Fix the bug in Feature X.
Change Request 3: Improve the performance of Feature X.
Change Request 4: Fix the bug in Feature X.
etc.
|
|
|
|
|
Ah, but we TRACKED those... If it was a REQUEST that came back...
That was VERY VERY BAD. (One programmer made a calculation error, and cost the company like $30,000 in penalties!)
So, those are:
Change Request 1: ...
FIX Request 1a: ... With Sitdown with manager...
FIX Request 1b: ... Client complains it's too slow... (Employee writeup begins, record in permanent file)
FIX Request 1c: ... New EMPLOYEE Assigned to the problem.
Honestly, we rarely made it passed a... If EVER. And WE were always more concerned about performance then the client.
In fact. I rewrote a piece of code, and took it from 5-7 SECONDS to < 1 second...
It was so fast, that I GOT IN TROUBLE because NOBODY thought it actually worked, and were complaining to their manager (they were not reading the screen, it was clear it worked. But there is NO WAY it could be that fast. LOL)...
|
|
|
|
|
A great manager uses metrics to highlight the great work his/her team is doing, a poor manager uses metrics like a slave master to try and protect his/her position.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
