Not talking about them, that's necessary.. I'm talking about co-workers who have the nerve to bitch at you because you didn't write an email well enough for their tastes. To hell with them.
Most the engineers I know (myself included) absolutely abhor unions.
Because most engineer types have massive egos and believe that their inherent brilliance places them above these filthy peasants who "must" collectively bargain to maintain their jobs.
They don't get paid for overtime in dollars, but in validation of their superiority complexes. That's worth more than money to these kind of people.
18 moths ago, I bought a Mac Pro. If there had bean a cheaper "non-all-in-one" Mac between the Mini and the Pro then I would probably have got one of those instead, and Apple would have significantly less of my money. They'd have had to wean at least one new customer away from Windows to compensate for that.
Judging from this thread and the opinions of many other people that I've spoken with, the problem is not that people don't want to switch, it's that the perception of lock-in keeps them from making the switch. If I had a dollar for every time I've heard "I like Apple products, but they're so expensive and you can't upgrade them," I could... afford a Mac Pro.
What's so great about "going far?" Moving into a project management role where I work 80 hours a week and have to introduce myself to my wife on the rare occasions that I see her? Having a bunch of juniors reporting to me that are all too busy trying to be the social butterflies that you suggest to the point that they can't do their work, which makes me look like an idiot? Putting on the vaseline-toothed happy face and slinging bullshit until I don't know what I actually believe?
No thanks, I'm happy right where I am. I don't want to be anybody's friend. Contrary to your belief, however, I don't want to be anybody's enemy, either.
While I understand the spirit of what you're saying, I'm not the least bit interested in my co-workers personal lives and I'm not a good enough actor to do anything but insult their intelligence if I try to talk to them about them.
The only thing I want from my co-workers is to work well together and that shouldn't require anything more than professional respect, not knowing their kids' names or what they like to do on the weekends.
I would have a mandatory national service policy. Every able-bodied young person upon graduating high school would either have to do a one year hitch in a branch of the military and two in the reserves, or two years of civilian service. Your choice. It's paid employment with free room and board.
Many of America's current cultural problems are, in my opinion, due to a lack of national identity. There are very few unifying experiences anymore and the USA has become very fragmented and provincial as a result.
We used to have a military service obligation and a peacetime draft and from what I can gather from talking to people of those generations, it helped all Americans feel connected, and gave those who served something to be proud of.
Elvis Presley got drafted, at the height of his popularity. It gave the impression that our country is so fair that even Elvis had to serve his time in the military.
This of course presupposes sane leadership w/r/t going to war. It wasn't the draft that made Vietnam such a tragedy, it was being there in the first place.
This is my philosophy. However, you'd be surprised how many people in this business still think that a programmer doesn't give a shit because they don't code at home.
Nobody works harder than me when I'm at work. But, at home I do other things (my hobbies tend towards the arts). I only code at home when there's something that I really want to learn and my job isn't giving me the opportunity to learn it. I don't go to user groups or do any of that stuff. About 60% of the programmers that I encounter think that because I do this that I don't have enough passion for software and have told me that they'd never hire me themselves. Their loss. I know what I'm capable of.
Consider the goal, not the means. The goal is documenting the code. Those who go against comments (me included) are not against documentation of the code. We are against documentation that may easily lose sync with the code, where better forms of documentation exist.
Yes, maintaining documentation in comments requires a certain amount of discipline. But if you don't have the discipline necessary to maintain comments, you're not going to have the discipline to write code that is as clear as XP thinks it should be.
Of course, most developers think they're perfect and infallible, so they will never admit that they don't have this discipline, and continue with their bad habits.
Furthermore, what is clear in code to one programmer isn't necessarily going to be clear to another. Human-language comments provide a lowest common denominator of clarity.
Remember, bad/wrong documentation is worse than no documentation.
Documentation is for intent. Documentation that is out of date can at least explain the intent of a piece of code, which will help a good developer deduce what is really going on.
Then, being a good developer, they will fix the documentation.
If the application is "done" and no major components are to be added, then by all means leave it alone.
However, most systems aren't like that. They need to be changed due to changes in requirements, new functionality, business rules, etc., and that's where refactoring helps you - it helps isolate functionality and help the system evolve. (The app should have been designed with that in mind from the beginning, but you and I both know that it never is.)
The main problem I have with refactoring (both the book and the concept) is that it's way too easy to go overboard with it because it presents a Right Way of writing code. Sometimes methods need to be 20 lines, sometimes classes need to do more than one thing, sometimes inheritance just gets in the way. Fowler respects these ideas, but I've known people who read this book and take refactoring to its logical extreme, which results in overly fragmented code.
I also despise the XP directive to not comment code, which Fowler promotes.
In all it's a good book but it's best to read it when after you've had a few years of real world experience and you can tell what should and shouldn't be taken seriously.
The lack of first-class functions/methods in Java makes functional-style programming unnecessarily difficult.
Then use a different language that supports your pet features. First-class functions are a procedural hack and don't really belong in a truly OO design in the first place.
However, one could also argue that a design's "OO-ness" can never reach 100% no matter what language you use for implementation.
The map is shorter, less cluttered, has less potential for bugs, and ultimately easier to understand once you understand what map and lambda do. Which shouldn't take a long time for a competent programmer.
I find the second block to read much more clearly, and six months from now if the guy who wrote it got hit by a bus I wouldn't need to make sure the next guy knew what map and lambda did. It makes work really dull to write code like that, but you're not paying people to show off their knowledge of a language's esoteric syntactic sugar. You pay them to get the job done in the most effective way possible, which in the real world, means writing the clearest, most maintainable code possible given the constraints of the language.
FM2 is fantastic, don't let this guy's impatience get to you. They could have balanced the career mode a little better so that you don't need to repeat races for cash to level up, but there's so much to do that it almost rivals WoW in replayability.
It's quite simple. When people started expecting their work to also be fun, or a vehicle for personal fulfillment, they stopped minding when they were asked to work outside of office hours.
To some of us, a job is something that we do for a paycheck. That means that we don't want to live "the lifestyle" and that we don't want our personal time to be intruded upon. You have to value something in your life higher than your work in order to understand this.
The no-comments maxim of Agile is, frankly, horseshit. Kent Beck came up with it to sell books to people who don't like writing in English. It's nothing but a rationalization for egomaniacs who think they are incapable of writing bad code.
Do you have a cast-iron photographic memory that can always recall what you were thinking at any given moment, six months later? I know I don't. But most programmers think they're infallible and that their code is perfect. They forget that someday someone else is going to have to work on this stuff, and what makes sense to you will likely be complete gibberish to everyone else.
I've seen the long-term effects of this philosophy and it's not pretty. I recently worked in a mature (4+ years) codebase that had been Agile from the start. It was a horrible, convoluted morass of spaghetti, mixing poorly designed classes and refactored-to-metrics code that used 10 methods and 5 classes to do what one sanely designed method would do. There were massive bugs that nobody could find, the code was inefficient, it took a good six months to get the best people in town trained well enough to work on it (and this place hired all contractors so they were writing their code as flashy as possible to show off just in case the other guys on their team happened to interview them for their next assignment).
I won't consider many programming practices to be completely invalid, but refusing to comment is one of them, and I will not work in such an environment again. It is a sign of stubbornness and hubris and neither of those are agile states of mind.
Worse yet, most of that immense number of branches will never be taken by anoyne. Most players play consistently all good or all evil, at least on the major issues. Branches and quests that would be only visible if you play good once, evil twice, neutral once, and good again, would be seen by maybe 0.1% of the players, so they'd be a major waste.
And you'd have to support all of the munchkins that have to do everything that's possible in a game. "I killed Plotz, Gary, and saved Clyde, but now I can't get the Pwnage Crystal. Gamefaqs says I'm supposed to get it if my alignment is.2028798012398012. Halp"
Having an immutable main quest and X number of "optional" side quests seems to be the best bang for the buck. It wasn't the main quest that made KOTOR great. It was the side quests and the characters.
Slashdot Mirror
100% of the day is 24 hours. That means that the typical manager perceives you as only giving 33% of your potential effort. Keep this in mind.
Not talking about them, that's necessary.. I'm talking about co-workers who have the nerve to bitch at you because you didn't write an email well enough for their tastes. To hell with them.
Most the engineers I know (myself included) absolutely abhor unions.
Because most engineer types have massive egos and believe that their inherent brilliance places them above these filthy peasants who "must" collectively bargain to maintain their jobs.
They don't get paid for overtime in dollars, but in validation of their superiority complexes. That's worth more than money to these kind of people.
18 moths ago, I bought a Mac Pro. If there had bean a cheaper "non-all-in-one" Mac between the Mini and the Pro then I would probably have got one of those instead, and Apple would have significantly less of my money. They'd have had to wean at least one new customer away from Windows to compensate for that.
Judging from this thread and the opinions of many other people that I've spoken with, the problem is not that people don't want to switch, it's that the perception of lock-in keeps them from making the switch. If I had a dollar for every time I've heard "I like Apple products, but they're so expensive and you can't upgrade them," I could... afford a Mac Pro.
Why would I want to call or go talk to someone who has such a shitty attitude that they are even assholes about how you write them an email?
The decline of email etiquette is self-perpetuating.
What's so great about "going far?" Moving into a project management role where I work 80 hours a week and have to introduce myself to my wife on the rare occasions that I see her? Having a bunch of juniors reporting to me that are all too busy trying to be the social butterflies that you suggest to the point that they can't do their work, which makes me look like an idiot? Putting on the vaseline-toothed happy face and slinging bullshit until I don't know what I actually believe? No thanks, I'm happy right where I am. I don't want to be anybody's friend. Contrary to your belief, however, I don't want to be anybody's enemy, either.
While I understand the spirit of what you're saying, I'm not the least bit interested in my co-workers personal lives and I'm not a good enough actor to do anything but insult their intelligence if I try to talk to them about them.
The only thing I want from my co-workers is to work well together and that shouldn't require anything more than professional respect, not knowing their kids' names or what they like to do on the weekends.
At least one large local company has fired people for being seen using competitors' products in public while wearing a company uniform.
This company also does random drug testing by the hair method.
People still line up to work there because of the benefits and perks.
Fucking sheep.
I would have a mandatory national service policy. Every able-bodied young person upon graduating high school would either have to do a one year hitch in a branch of the military and two in the reserves, or two years of civilian service. Your choice. It's paid employment with free room and board.
Many of America's current cultural problems are, in my opinion, due to a lack of national identity. There are very few unifying experiences anymore and the USA has become very fragmented and provincial as a result.
We used to have a military service obligation and a peacetime draft and from what I can gather from talking to people of those generations, it helped all Americans feel connected, and gave those who served something to be proud of.
Elvis Presley got drafted, at the height of his popularity. It gave the impression that our country is so fair that even Elvis had to serve his time in the military.
This of course presupposes sane leadership w/r/t going to war. It wasn't the draft that made Vietnam such a tragedy, it was being there in the first place.
Why did you interview a Java developer when you're actually looking for a C developer?
This is my philosophy. However, you'd be surprised how many people in this business still think that a programmer doesn't give a shit because they don't code at home.
Nobody works harder than me when I'm at work. But, at home I do other things (my hobbies tend towards the arts). I only code at home when there's something that I really want to learn and my job isn't giving me the opportunity to learn it. I don't go to user groups or do any of that stuff. About 60% of the programmers that I encounter think that because I do this that I don't have enough passion for software and have told me that they'd never hire me themselves. Their loss. I know what I'm capable of.
Consider the goal, not the means. The goal is documenting the code. Those who go against comments (me included) are not against documentation of the code. We are against documentation that may easily lose sync with the code, where better forms of documentation exist.
Yes, maintaining documentation in comments requires a certain amount of discipline. But if you don't have the discipline necessary to maintain comments, you're not going to have the discipline to write code that is as clear as XP thinks it should be.
Of course, most developers think they're perfect and infallible, so they will never admit that they don't have this discipline, and continue with their bad habits.
Furthermore, what is clear in code to one programmer isn't necessarily going to be clear to another. Human-language comments provide a lowest common denominator of clarity.
Remember, bad/wrong documentation is worse than no documentation.
Documentation is for intent. Documentation that is out of date can at least explain the intent of a piece of code, which will help a good developer deduce what is really going on.
Then, being a good developer, they will fix the documentation.
If the application is "done" and no major components are to be added, then by all means leave it alone.
However, most systems aren't like that. They need to be changed due to changes in requirements, new functionality, business rules, etc., and that's where refactoring helps you - it helps isolate functionality and help the system evolve. (The app should have been designed with that in mind from the beginning, but you and I both know that it never is.)
The main problem I have with refactoring (both the book and the concept) is that it's way too easy to go overboard with it because it presents a Right Way of writing code. Sometimes methods need to be 20 lines, sometimes classes need to do more than one thing, sometimes inheritance just gets in the way. Fowler respects these ideas, but I've known people who read this book and take refactoring to its logical extreme, which results in overly fragmented code.
I also despise the XP directive to not comment code, which Fowler promotes.
In all it's a good book but it's best to read it when after you've had a few years of real world experience and you can tell what should and shouldn't be taken seriously.
How would the cars know where to go? Data from the roads.
Who owns the roads? The state and federal governments.
Even if the states own them, how are state departments of transportation funded? Largely by federal grants.
Now, who has a detailed record of everywhere you have gone in your spiffy new self-driving automobile?
The lack of first-class functions/methods in Java makes functional-style programming unnecessarily difficult.
Then use a different language that supports your pet features. First-class functions are a procedural hack and don't really belong in a truly OO design in the first place.
However, one could also argue that a design's "OO-ness" can never reach 100% no matter what language you use for implementation.
The map is shorter, less cluttered, has less potential for bugs, and ultimately easier to understand once you understand what map and lambda do. Which shouldn't take a long time for a competent programmer.
I find the second block to read much more clearly, and six months from now if the guy who wrote it got hit by a bus I wouldn't need to make sure the next guy knew what map and lambda did. It makes work really dull to write code like that, but you're not paying people to show off their knowledge of a language's esoteric syntactic sugar. You pay them to get the job done in the most effective way possible, which in the real world, means writing the clearest, most maintainable code possible given the constraints of the language.
Call me when you do and then I might listen to your arguments.
THIS is what's killing Linux on the desktop, people.
FM2 is fantastic, don't let this guy's impatience get to you. They could have balanced the career mode a little better so that you don't need to repeat races for cash to level up, but there's so much to do that it almost rivals WoW in replayability.
No, see, they got Roger Clemens to play Duke. That's why it's taking so long, he keeps retiring and coming back.
I'd rather play like this was the first game I'd ever seen in my life.
Knowing how things work takes all the fun out of them.
b-b-b-but we're all precious snowflakes who would rather eat shit than have our jobs can't be devalued by collective bargaining!
That's the attitude of American IT workers.
It's quite simple. When people started expecting their work to also be fun, or a vehicle for personal fulfillment, they stopped minding when they were asked to work outside of office hours.
To some of us, a job is something that we do for a paycheck. That means that we don't want to live "the lifestyle" and that we don't want our personal time to be intruded upon. You have to value something in your life higher than your work in order to understand this.
The no-comments maxim of Agile is, frankly, horseshit. Kent Beck came up with it to sell books to people who don't like writing in English. It's nothing but a rationalization for egomaniacs who think they are incapable of writing bad code.
Do you have a cast-iron photographic memory that can always recall what you were thinking at any given moment, six months later? I know I don't. But most programmers think they're infallible and that their code is perfect. They forget that someday someone else is going to have to work on this stuff, and what makes sense to you will likely be complete gibberish to everyone else.
I've seen the long-term effects of this philosophy and it's not pretty. I recently worked in a mature (4+ years) codebase that had been Agile from the start. It was a horrible, convoluted morass of spaghetti, mixing poorly designed classes and refactored-to-metrics code that used 10 methods and 5 classes to do what one sanely designed method would do. There were massive bugs that nobody could find, the code was inefficient, it took a good six months to get the best people in town trained well enough to work on it (and this place hired all contractors so they were writing their code as flashy as possible to show off just in case the other guys on their team happened to interview them for their next assignment).
I won't consider many programming practices to be completely invalid, but refusing to comment is one of them, and I will not work in such an environment again. It is a sign of stubbornness and hubris and neither of those are agile states of mind.
You can already play as a Johnson in Second Life.
Oh, wait...
When humanity dies, the universe dies also.
Worse yet, most of that immense number of branches will never be taken by anoyne. Most players play consistently all good or all evil, at least on the major issues. Branches and quests that would be only visible if you play good once, evil twice, neutral once, and good again, would be seen by maybe 0.1% of the players, so they'd be a major waste.
And you'd have to support all of the munchkins that have to do everything that's possible in a game. "I killed Plotz, Gary, and saved Clyde, but now I can't get the Pwnage Crystal. Gamefaqs says I'm supposed to get it if my alignment is
Having an immutable main quest and X number of "optional" side quests seems to be the best bang for the buck. It wasn't the main quest that made KOTOR great. It was the side quests and the characters.