Combination of burnout and no longer doing what I enjoy.
The burnout came during a really rough, 3-year development cycle. We spent three months planning with the principal team. They approved the plans and let us run in one direction for a year before dropping a bombshell on ALL the partner teams. We had to drop what we were doing and start over with a completely new (and woefully incomplete) API, tool chain, and environment. Roughest two years I've spent in software ever.
Had a former manager swoop in and rescue a number of us. Spent three years learning new stuff and enjoying my work and team. Then a big re-org came. Moved to something I'm not really enjoying and I can feel the "don't give a shit" attitude building up.
Top it off with a death in the family and it's time to go.
Fortunately, a great stock and housing market will allow me and my partner to enjoy some time off. Hopefully a year or two of doing what I want to do and exploring topics I want to learn will help clarify things. I'll find my passion for the work again or find another thing to fire my passion.
Good point about the Data Breach Incident. Granted, NewEgg is not in the business of wiping drives but if this does qualify as a DBI then NewEgg may have some liability here. This would be similar to pawn shop owner that receives and resells stolen property. Even if the owner wasn't aware that it was stolen, they still have some liability if they didn't do their due diligence to find out.
IANAL, but you might consider sending the drive back and explaining the situation to NewEgg. If it's not a DBI, they'll wipe the drive and restock it. If it does qualify as a DBI, you might just have spared them some legal hassles.
I wholeheartedly second that recommendation. I've been reading Linux Format for the last several years and I've enjoyed almost every issue. The writing is fresh, engaging, and above all, useful.
Some of their humor reminds me of Marcel Gagne from older issues of Linux Journal.
This sounds suspiciously like part of the Stephen King story "The End of the Whole Mess": http://en.wikipedia.org/wiki/The_End_of_the_Whole_Mess. Are we sure they're going for geothermal power and not an attempt to "pacify" humanity? Just asking...
Unfortunately, managers love the term "granularity" and have been using it as a cudgel. They've locked on to "Agile" programming and SCRUM project management as methods for driving this granularity into the development and test processes. They want tasks broken down to 15 minute increments and balk when any task takes more than a couple of hours to complete. All this so that they can achieve "visibility" and "predictability" for a given project, i.e. they get more status reports with pretty charts and graphs. I really despise the term "burn down" which springs from the whole thing as well.
Now, I may sound bitter about this but, I do understand that for all parties involved in a project, especially a large scale project; there needs to be an understanding of where team is at, where it's headed, and where the bottlenecks are located. This is not any easy problem to solve; it involves lots of guess work and dependency graphs that would make Euler weep. I suppose that's what makes it all the more irritating when managers think they have yet-another-silver-bullet for project management that they misuse causing more Maker frustration and possibly increasing the chance for failure rather than ameliorating it.
I too am surprised that Mandriva did not make the grade.
As for an inaccurate view of the French mindset, I would posit that, none of us have a clear view of each others mindset on a personal level, much less a cultural level.
Then again, the French government is the only one, outside of a George Orwell novel, that has an agency dedicated to "language purity".
You can also turn on the "Snap To" option in the Mouse Properties dialog in the Control Panel; it's on the "Pointer Options" tab. This will automatically move the mouse to the default button on dialogs. It should help cut down the number of mouse moves the user has to do themselves.
The speech has the feel of a eulogy, high praise for "our dear, departed friend". I suppose one should wait until the body is in the ground, or out the door, before heaping dirt on it.
I agree in principle, switching from old, reliable systems to new unproven systems is risky at best. The FAA however has done this for decades.
I recall an NPR article from the earyly 90's regarding FAA upgrades the the nations air traffic control systems. The article covered the fact that, the FAA had been using emulators on top of emulators for years because the hardware was not only kaput but, so was the company that made it and the plans/schematics were no where to be found.
Nice thought to keep in mind the next time you fly.
Indeed it is difficult. I too work at a large software company and we have a full time test team. We do separate the responsibilities of writing and maintaining the tests from actually running the tests. The execution team's job is to use lab machines to execute the tests in whatever configurations we wish to support. They rely heavily on automation to format, install the OS, configure the machine, install the product, and execute the tests. Results are then posted on a team website and tracked via database. Any failures are reported to the appropriate testers for investigation and resolution, e.g. new product bug, old product bug come back to haunt, test bug, etc. Division of labor and responsibility makes a big difference between successful and unsuccessful test automation.
And, true to fashion, management does indeed believe that the tests, once written, don't have to be modified. Even though they are often involved in the decision to make changes to a feature, they don't understand the impact of the changes on the tests. Here, it is up to the feature PM's, Devs and Testers to communicate and work together to make sure that updates to the tests mirror changes to the feature.
Write automation at all levels: UI, middle-tier and data-level. You can also write mock objects to simulate the other layers, e.g. the database layer, so you can test each layer in isolation. This takes some effort to design and implement properly. Just treat it as part of the developement effort from the start. That way, writing test automation becomes part of the fun. Don't wait to design and create tests for your code. That's a sure-fire reciepe for creating buggy software.
Slashdot Mirror
Combination of burnout and no longer doing what I enjoy.
The burnout came during a really rough, 3-year development cycle. We spent three months planning with the principal team. They approved the plans and let us run in one direction for a year before dropping a bombshell on ALL the partner teams. We had to drop what we were doing and start over with a completely new (and woefully incomplete) API, tool chain, and environment. Roughest two years I've spent in software ever.
Had a former manager swoop in and rescue a number of us. Spent three years learning new stuff and enjoying my work and team. Then a big re-org came. Moved to something I'm not really enjoying and I can feel the "don't give a shit" attitude building up.
Top it off with a death in the family and it's time to go.
Fortunately, a great stock and housing market will allow me and my partner to enjoy some time off. Hopefully a year or two of doing what I want to do and exploring topics I want to learn will help clarify things. I'll find my passion for the work again or find another thing to fire my passion.
Good point about the Data Breach Incident. Granted, NewEgg is not in the business of wiping drives but if this does qualify as a DBI then NewEgg may have some liability here. This would be similar to pawn shop owner that receives and resells stolen property. Even if the owner wasn't aware that it was stolen, they still have some liability if they didn't do their due diligence to find out.
IANAL, but you might consider sending the drive back and explaining the situation to NewEgg. If it's not a DBI, they'll wipe the drive and restock it. If it does qualify as a DBI, you might just have spared them some legal hassles.
Just my 2p.
I wholeheartedly second that recommendation. I've been reading Linux Format for the last several years and I've enjoyed almost every issue. The writing is fresh, engaging, and above all, useful.
Some of their humor reminds me of Marcel Gagne from older issues of Linux Journal.
This sounds suspiciously like part of the Stephen King story "The End of the Whole Mess": http://en.wikipedia.org/wiki/The_End_of_the_Whole_Mess. Are we sure they're going for geothermal power and not an attempt to "pacify" humanity? Just asking...
Cool. Does it say "Front toward Assailant" on it? Those with Army or Marine Corps service will know what I'm talking about.
Unfortunately, managers love the term "granularity" and have been using it as a cudgel. They've locked on to "Agile" programming and SCRUM project management as methods for driving this granularity into the development and test processes. They want tasks broken down to 15 minute increments and balk when any task takes more than a couple of hours to complete. All this so that they can achieve "visibility" and "predictability" for a given project, i.e. they get more status reports with pretty charts and graphs. I really despise the term "burn down" which springs from the whole thing as well.
Now, I may sound bitter about this but, I do understand that for all parties involved in a project, especially a large scale project; there needs to be an understanding of where team is at, where it's headed, and where the bottlenecks are located. This is not any easy problem to solve; it involves lots of guess work and dependency graphs that would make Euler weep. I suppose that's what makes it all the more irritating when managers think they have yet-another-silver-bullet for project management that they misuse causing more Maker frustration and possibly increasing the chance for failure rather than ameliorating it.
Sorry, end of rant.
I for one welcome our new Galactic Overlord.
From Hell's heart, I stab at thee!
For hate's sake, I spit my last breath at thee!
Priest: And thus spake the Great Devil Kahn at our saviour, The Kirk. Here endeth the lesson.
Congregation: More power to the engines!
I too am surprised that Mandriva did not make the grade.
As for an inaccurate view of the French mindset, I would posit that, none of us have a clear view of each others mindset on a personal level, much less a cultural level.
Then again, the French government is the only one, outside of a George Orwell novel, that has an agency dedicated to "language purity".
You can also turn on the "Snap To" option in the Mouse Properties dialog in the Control Panel; it's on the "Pointer Options" tab. This will automatically move the mouse to the default button on dialogs. It should help cut down the number of mouse moves the user has to do themselves.
Nice. A very poignant, and poetic analogy.
What are you doing on Slashdot?
The speech has the feel of a eulogy, high praise for "our dear, departed friend". I suppose one should wait until the body is in the ground, or out the door, before heaping dirt on it.
Boy, won't their faces be red!
I believe that we've seen this before on an old Discovery Channel show called,"The Next Step". These were prototyped in Japan more than ten years ago.
I guess they didn't catch on as quickly as was hoped.
I agree in principle, switching from old, reliable systems to new unproven systems is risky at best. The FAA however has done this for decades.
I recall an NPR article from the earyly 90's regarding FAA upgrades the the nations air traffic control systems. The article covered the fact that, the FAA had been using emulators on top of emulators for years because the hardware was not only kaput but, so was the company that made it and the plans/schematics were no where to be found.
Nice thought to keep in mind the next time you fly.
Indeed it is difficult. I too work at a large software company and we have a full time test team. We do separate the responsibilities of writing and maintaining the tests from actually running the tests. The execution team's job is to use lab machines to execute the tests in whatever configurations we wish to support. They rely heavily on automation to format, install the OS, configure the machine, install the product, and execute the tests. Results are then posted on a team website and tracked via database. Any failures are reported to the appropriate testers for investigation and resolution, e.g. new product bug, old product bug come back to haunt, test bug, etc. Division of labor and responsibility makes a big difference between successful and unsuccessful test automation.
And, true to fashion, management does indeed believe that the tests, once written, don't have to be modified. Even though they are often involved in the decision to make changes to a feature, they don't understand the impact of the changes on the tests. Here, it is up to the feature PM's, Devs and Testers to communicate and work together to make sure that updates to the tests mirror changes to the feature.
Write automation at all levels: UI, middle-tier and data-level. You can also write mock objects to simulate the other layers, e.g. the database layer, so you can test each layer in isolation. This takes some effort to design and implement properly. Just treat it as part of the developement effort from the start. That way, writing test automation becomes part of the fun. Don't wait to design and create tests for your code. That's a sure-fire reciepe for creating buggy software.