You are viewing a single comment's thread.

view the rest of the comments →

0
3

[–] 13043165? 0 points 3 points (+3|-0) ago 

Maybe of interest I have 30+ years of programming experience. I lost count but worked in small companies of 3 people to the biggest companies. My range goes from scientific programming to building mailing server software that can process mails at massive scale and where you could pull the power cable without losing any mail.

I also worked with 100+ maybe even 200+ other developers. My work covers critical systems to very complex large scale systems.

Around 2000 I tried Extreme Programming where 2 developers were sitting behind one PC and keyboard.

  • Yes fuzzy deadlines. Dead line are good but they should be movable. The difference between success or failure can be mere minutes. The reason why all my SCRUM tasks succeed is because I only take those that I can guarantee to complete. I won't touch one that is destined to fail.

  • Years before I get a problem to solve, I already observe how a company functions, how the business works, how It works,.... I am going to try to predict what I will needed in the future and already start to create code that may be needed for the future. Stupid stuff like a class to measure time easily. Small parts where I experiment with that could become something I need quickly. Just like Rembrandt would have a notebook and drag quick stuff that he may later use in a master-peace)

  • I worked in a small company, I got burned by inheriting a project by an expert that failed at a client. So I ended up with weeks of support an no way to solve it. My code evolved to make sure that my first release will be spot on with zero defects.

  • I have a winners mentality. I don't want to win against my team members I don't care if they are better or worse, but I want to win the deadline with zero defects or bugs. So the mentality is to get the maximum I can get out of my body like a top athlete.

  • Some of my software runs on very critical systems. I take great responsibility to get the code right so that people or equipment do not get damaged. I once worked at industrial software where a fault in my code could blow up the company. Safety of people, reliability, security and privacy is important for me. However when you are in a SCRUM team it is easy to relies on the others to fix your bad code.

  • By reordering my social live dynamically I get the best productivity for the least stress and the best social life.

The issue I have is that this whole SCRUM madness is killing any productivity and causes enormous stress that should never been there in the first place. It is destroying my and the other team members health. However I have learned ho to deal with the kind of stress the others don't and will burn-out.

0
1

[–] FroggyHunter 0 points 1 point (+1|-0) ago 

I understand your points now. Once again, thank you for your time!

0
0

[–] BlowjaySimpson ago 

Thank you for this. As someone who is a self-taught programmer working at a large company, I have found that advice like this from veterans like you is some of the best stuff to internalize and emulate.

0
1

[–] 13048439? 0 points 1 point (+1|-0) ago 

Learning to dose your mental energy like a top sporter would is the key. :-)