Repositories of old knowledge versus new. Old knowledge should not be undervalued as times change, but people don't. The folks who run the libraries, preserve and order knowledge, cannot be overvalued. Plus, libraries seem to be much more fault tolerant than your Blu-Ray archive of Wikipedia.
Yeah, so you labor those 55 hours a week working hand-in-hand with idiot consultants earning twice as much money as you; all the while trying to meet that arbitrary deadline. So, what? You know that the Thank You email and the $10 bag of candy bars makes it totally worthwhile.
Honestly, *krinkle* those consultants *crunch* are so *chew,chew,chew* stupid.
I have no direct experience or knowledge, but I'd imagine... Brilliant! That's my new slashdot tagline.
But seriously, I agree. There's something to be said for working with people who are passionate about their work and discipline. If I like purple cool-aid and they serve purple cool-aid, then even better.
I suppose it depends on the culture, but at my current employer it's customary to send an email to his IT superior thanking the team for their effort for the current release. This may depend upon the depth of your organization. In general, non-IT business doesn't give a squat about IT politics. Their only concern is that their infrastructure is producing happy customers and revenue (or maybe just revenue). It sounds like you work for a junior manager or maybe a mid-level mechanical manager. A seasoned manager understands that this meaningless gesture costs him nothing and encourages the more hapless employees to work harder.
There is a rarer, malevolent form of manager that will take all the credit for his subordinates' work. I hear about this often in larger consulting firms. However, this can be "managed" as well. These types usually have no inherent technical talent. So, they'll latch on to the most talented folks and generally try to appease them. This relationship is feast or famine as they'll be quick to blame you for failure or replace you if a more qualified candidate arrives.
My advice is as follows:
1. Verbal praise is meaningless (we're all NT personalities here right?). However, you should be respectful, if indifferent, with regard to it because it still goes a long way with some employees and some managers even convince themselves that they're super benevolent for providing it. I like to explain to managers, in private, early in our relationship that I prefer my recognition in monetary format (and that doesn't mean a Starbucks gift card).
The death nell is when you start receiving shiny chunks of plastic with your name etched into them. This means that the company recognizes your hard work, but cannot pay you more money. It's an indicator that you need to a) not work so hard, b) get promoted, or c) find a better job.
2. Most well adjusted people think that they're great at their jobs (just like they're great drivers). You have to work hard to find perspective.
A good indicator of your skill level is how your peers relate to you. If they come to you for advice or help, then you're doing well (or you're overqualified for your position). You should concentrate on how you are publicly recognized with regard to your peers. Don't let kiss-asses step over you.
Another indicator is how well-known you are to your superior's peers. If you're the right hand, then they should know your name. Otherwise, your manager may be trying to "hide you" which may prevent your from getting more visible work.
3. Good managers take a lot of shit from people every day and have a million things to track. You can ingratiate yourself by providing him with the information he needs in a timely fashion without lots of prompting. I don't consider this kissing ass, but rather being a good employee. Managing Humans is a fun book to start profiling managers. Just be careful! There's always the danger that if you understand them too well, then you may end up as one.
Developers are most productive when they are in the groove. Distractions kill productivity. I would argue that's true to a point. Once you've exceeded a couple of hours, then it's useful to have a distraction. Otherwise, you end up with poorly designed, monolithic chunks of code. If you fully designed beforehand, then it would be less of a problem...but that's just crazy talk.
Ditto, one man's boredom is another man's serenity. I grew up farming as well. In small scale farming you set your own hours, you don't have to deal with people, you perform a lot of honest physical labor, you use ingenuity to solve problems and fix things that break.
I have a ton of respect for farmers. It's not a bad job in general. It just doesn't pay for shit. It does make me appreciate the air conditioning on those really hot days.
This applies mostly to programmers who write functions. Developers who create objects with methods usually don't require blocks of code "pages" long. I'll give a by to computer scientists implementing algorithms because the developers will encapsulate their code for them.
I blame one-shot college CS projects. These long chunks are usually the result of a procrastinator cranking out the code in one sitting. That shopping list will work well enough to turn it in for a grade. If it doesn't then build and fix with liberal use of a pretty IDE debugger will find the bugs. You won't understand the code next month, but that doesn't matter. You won't be able to reuse or extend that code, but that doesn't matter.
Try maintaining that same code over the course of years. Try debugging that code when it's running in a distributed system in production. If colleges made students maintain legacy systems as part of their trials, then code would be much cleaner, with much more logging, and we'd all be a lot happier.
--What does static do? I dunno, I think it makes it faster. Then let's make it all static.
MAARS
Weight: 235 lb.
Speed: 7 mph
Weapons: M240B medium machine gun Notable feature: Programmable no-fire zones to prevent fratricide.
Butch: Hurry up! We're taking heavy fire.
Andy: Hold on we're still writing our test cases.
Paul: No, Andy, that code protects soldiers on both the left and right sides. My test case only requires you to protect the left side. You're clearly gold plating.
Repositories of old knowledge versus new. Old knowledge should not be undervalued as times change, but people don't. The folks who run the libraries, preserve and order knowledge, cannot be overvalued. Plus, libraries seem to be much more fault tolerant than your Blu-Ray archive of Wikipedia.
I second. Openfire and Pidgin, Spark, etc.
Bah, he should just get the NSA or one of the CIA's tech firms to build him one.
Yeah, so you labor those 55 hours a week working hand-in-hand with idiot consultants earning twice as much money as you; all the while trying to meet that arbitrary deadline. So, what? You know that the Thank You email and the $10 bag of candy bars makes it totally worthwhile.
Honestly, *krinkle* those consultants *crunch* are so *chew,chew,chew* stupid.
But seriously, I agree. There's something to be said for working with people who are passionate about their work and discipline. If I like purple cool-aid and they serve purple cool-aid, then even better.
I suppose it depends on the culture, but at my current employer it's customary to send an email to his IT superior thanking the team for their effort for the current release. This may depend upon the depth of your organization. In general, non-IT business doesn't give a squat about IT politics. Their only concern is that their infrastructure is producing happy customers and revenue (or maybe just revenue). It sounds like you work for a junior manager or maybe a mid-level mechanical manager. A seasoned manager understands that this meaningless gesture costs him nothing and encourages the more hapless employees to work harder.
There is a rarer, malevolent form of manager that will take all the credit for his subordinates' work. I hear about this often in larger consulting firms. However, this can be "managed" as well. These types usually have no inherent technical talent. So, they'll latch on to the most talented folks and generally try to appease them. This relationship is feast or famine as they'll be quick to blame you for failure or replace you if a more qualified candidate arrives.
My advice is as follows:
1. Verbal praise is meaningless (we're all NT personalities here right?). However, you should be respectful, if indifferent, with regard to it because it still goes a long way with some employees and some managers even convince themselves that they're super benevolent for providing it. I like to explain to managers, in private, early in our relationship that I prefer my recognition in monetary format (and that doesn't mean a Starbucks gift card).
The death nell is when you start receiving shiny chunks of plastic with your name etched into them. This means that the company recognizes your hard work, but cannot pay you more money. It's an indicator that you need to a) not work so hard, b) get promoted, or c) find a better job.
2. Most well adjusted people think that they're great at their jobs (just like they're great drivers). You have to work hard to find perspective.
A good indicator of your skill level is how your peers relate to you. If they come to you for advice or help, then you're doing well (or you're overqualified for your position). You should concentrate on how you are publicly recognized with regard to your peers. Don't let kiss-asses step over you.
Another indicator is how well-known you are to your superior's peers. If you're the right hand, then they should know your name. Otherwise, your manager may be trying to "hide you" which may prevent your from getting more visible work.
3. Good managers take a lot of shit from people every day and have a million things to track. You can ingratiate yourself by providing him with the information he needs in a timely fashion without lots of prompting. I don't consider this kissing ass, but rather being a good employee. Managing Humans is a fun book to start profiling managers. Just be careful! There's always the danger that if you understand them too well, then you may end up as one.
Preach on brother. What Apple has done is terrible. They should be awarded the Methuselah Mouse prize.
Ditto, one man's boredom is another man's serenity. I grew up farming as well. In small scale farming you set your own hours, you don't have to deal with people, you perform a lot of honest physical labor, you use ingenuity to solve problems and fix things that break.
I have a ton of respect for farmers. It's not a bad job in general. It just doesn't pay for shit. It does make me appreciate the air conditioning on those really hot days.
This applies mostly to programmers who write functions. Developers who create objects with methods usually don't require blocks of code "pages" long. I'll give a by to computer scientists implementing algorithms because the developers will encapsulate their code for them.
I blame one-shot college CS projects. These long chunks are usually the result of a procrastinator cranking out the code in one sitting. That shopping list will work well enough to turn it in for a grade. If it doesn't then build and fix with liberal use of a pretty IDE debugger will find the bugs. You won't understand the code next month, but that doesn't matter. You won't be able to reuse or extend that code, but that doesn't matter.
Try maintaining that same code over the course of years. Try debugging that code when it's running in a distributed system in production. If colleges made students maintain legacy systems as part of their trials, then code would be much cleaner, with much more logging, and we'd all be a lot happier.
--What does static do? I dunno, I think it makes it faster. Then let's make it all static.
MAARS
Weight: 235 lb.
Speed: 7 mph
Weapons: M240B medium machine gun
Notable feature: Programmable no-fire zones to prevent fratricide.
Butch: Hurry up! We're taking heavy fire.
Andy: Hold on we're still writing our test cases.
Paul: No, Andy, that code protects soldiers on both the left and right sides. My test case only requires you to protect the left side. You're clearly gold plating.