I am so sick of being a developer :-(
-
After having just sat through a 1:15 meeting (18 people * 1:15 = 22.5 man hours!) listening to people going around and around in circles about best practices and how to improve process, making the same mistakes that just about every other company that ever existed has also already made. I might just go back to Thailand and become a monk (I'm not kidding!). Maybe I could be called Phra l33t :-) Problem is, I really love developing :(( /end_rant
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
-
After having just sat through a 1:15 meeting (18 people * 1:15 = 22.5 man hours!) listening to people going around and around in circles about best practices and how to improve process, making the same mistakes that just about every other company that ever existed has also already made. I might just go back to Thailand and become a monk (I'm not kidding!). Maybe I could be called Phra l33t :-) Problem is, I really love developing :(( /end_rant
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
You weren't in the same meeting as me then were you?;P And they still ran faster and faster and faster, till they all just melted away, and there was nothing left but a great big pool of melted butter "I ask candidates to create an object model of a chicken." -Bruce Eckel
-
After having just sat through a 1:15 meeting (18 people * 1:15 = 22.5 man hours!) listening to people going around and around in circles about best practices and how to improve process, making the same mistakes that just about every other company that ever existed has also already made. I might just go back to Thailand and become a monk (I'm not kidding!). Maybe I could be called Phra l33t :-) Problem is, I really love developing :(( /end_rant
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
Perhaps you can try to be a developer in a monastry, making it the most technological advanced one in the world.... :~ Weiye, Chen When pursuing your dreams, don't forget to enjoy your life...
-
Perhaps you can try to be a developer in a monastry, making it the most technological advanced one in the world.... :~ Weiye, Chen When pursuing your dreams, don't forget to enjoy your life...
Weiye Chen wrote: Perhaps you can try to be a developer in a monastry, making it the most technological advanced one in the world.... Possibly. Some monks have TV's and aircon in their huts nowadays so why not Internet :-) Isn't there some monastery somewhere that offers confessions and absolution over the net...?
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
-
After having just sat through a 1:15 meeting (18 people * 1:15 = 22.5 man hours!) listening to people going around and around in circles about best practices and how to improve process, making the same mistakes that just about every other company that ever existed has also already made. I might just go back to Thailand and become a monk (I'm not kidding!). Maybe I could be called Phra l33t :-) Problem is, I really love developing :(( /end_rant
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
Taka Muraoka wrote: 1:15 meeting (18 people * 1:15 = 22.5 man hours!) Excellent seeing someone else calculating how much these crud meetings cost! Lets say in your group of 18 that there were 5 devs who were the ones really holding the show up. They should be taken outside and dealt to! A bit more of this treatment and they would quickly change there habits or quit working for the company. Taka Muraoka wrote: about best practices and how to improve process, This talk is crud and only makes things worse. In my experience managers hold meetings principally to justify their reason for existing, not to improve anything. Any manager who holds regular meetings is an obvious failure as a manager. Management is not about stopping people from working through holding meetings, but is about getting people to do what the manager wants rather than they want. And on a further note, managers that expect to be respected becaause they have a management job are morons. Respect should be gained and is not a right. Taka if enough of your co-workers feel the same way as you I suggest you revolt, and write to the directors of the company to get your management structure changed. Don't scre around at the CEO level as he/she is also obviously incompetent as well! Regardz Colin J Davies
Sonork ID 100.9197:Colin
Warning Link to the minion's animation, do not use. It's a real shame that people as stupid as you can work out how to use a computer. said by Christian Graus in the Soapbox
-
Taka Muraoka wrote: 1:15 meeting (18 people * 1:15 = 22.5 man hours!) Excellent seeing someone else calculating how much these crud meetings cost! Lets say in your group of 18 that there were 5 devs who were the ones really holding the show up. They should be taken outside and dealt to! A bit more of this treatment and they would quickly change there habits or quit working for the company. Taka Muraoka wrote: about best practices and how to improve process, This talk is crud and only makes things worse. In my experience managers hold meetings principally to justify their reason for existing, not to improve anything. Any manager who holds regular meetings is an obvious failure as a manager. Management is not about stopping people from working through holding meetings, but is about getting people to do what the manager wants rather than they want. And on a further note, managers that expect to be respected becaause they have a management job are morons. Respect should be gained and is not a right. Taka if enough of your co-workers feel the same way as you I suggest you revolt, and write to the directors of the company to get your management structure changed. Don't scre around at the CEO level as he/she is also obviously incompetent as well! Regardz Colin J Davies
Sonork ID 100.9197:Colin
Warning Link to the minion's animation, do not use. It's a real shame that people as stupid as you can work out how to use a computer. said by Christian Graus in the Soapbox
Hmmm... Interesting post :yikes: :-) Colin Davies wrote: They should be taken outside and dealt to It's not really the devs that are the cause of the problems. [edit] There are good devs and there are bad devs (i.e. inexperienced or less skillful) and there are devs in between. The trick is to manage the mix properly. Sure, there are people around that are so bad and/or disruptive that they need to be fired but there's no-one like that here. [/edit] Colin Davies wrote: And on a further note, managers that expect to be respected becaause they have a management job are morons. Respect should be gained and is not a right. Too true, in any area of life. Colin Davies wrote: Taka if enough of your co-workers feel the same way as you I suggest you revolt I'm a contractor here so I don't really have a personal stake in it. I just find it really depressing to see companies make the same mistakes over and over again. People who actually give a damn about what they do and want to do a good job can't because they're crippled by poor work practices and processes. Stuff that we, as an industry, should have surely learnt to know better about by now. Learning from your mistakes is all good and well but it's much smarter to learn from other people's mistakes. Then you don't have to make the mistakes even once! I had a long chat with someone recently about this kind of thing. The problem with technical people and things like this is that they think that the way to fix it is through technical solutions. Not realising that the *underlying* problems are caused by not understanding how people work, operate and communicate. In other words, social, interpersonal issues rather than technical issues.
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
-
Hmmm... Interesting post :yikes: :-) Colin Davies wrote: They should be taken outside and dealt to It's not really the devs that are the cause of the problems. [edit] There are good devs and there are bad devs (i.e. inexperienced or less skillful) and there are devs in between. The trick is to manage the mix properly. Sure, there are people around that are so bad and/or disruptive that they need to be fired but there's no-one like that here. [/edit] Colin Davies wrote: And on a further note, managers that expect to be respected becaause they have a management job are morons. Respect should be gained and is not a right. Too true, in any area of life. Colin Davies wrote: Taka if enough of your co-workers feel the same way as you I suggest you revolt I'm a contractor here so I don't really have a personal stake in it. I just find it really depressing to see companies make the same mistakes over and over again. People who actually give a damn about what they do and want to do a good job can't because they're crippled by poor work practices and processes. Stuff that we, as an industry, should have surely learnt to know better about by now. Learning from your mistakes is all good and well but it's much smarter to learn from other people's mistakes. Then you don't have to make the mistakes even once! I had a long chat with someone recently about this kind of thing. The problem with technical people and things like this is that they think that the way to fix it is through technical solutions. Not realising that the *underlying* problems are caused by not understanding how people work, operate and communicate. In other words, social, interpersonal issues rather than technical issues.
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
Taka Muraoka wrote: Learning from your mistakes is all good and well but it's much smarter to learn from other people's mistakes. Then you don't have to make the mistakes even once! True Taka, but some mistakes can be such fun they are worth repeating. :-) There is always a communication problem when a technical person has to talk to a non technical person. Imagine a group of technicians being managed by a non-technician. The results are terrible, the techs are never supplied with the right tools, they are given tasks that are either impossible or worthless. There is room for SAs in our world but very few of them can communicate well with technical people. Taka Muraoka wrote: In other words, social, interpersonal issues rather than technical issues. Yes a lot of developers fail terribly here, however the management should put in place physical systems so this can be minimised. Too often I have seen management create a time-line for a project with no input from the developers etc. The social skills really are up to the managemnet to have and not the techs. Regardz Colin J Davies
Sonork ID 100.9197:Colin
Warning Link to the minion's animation, do not use. It's a real shame that people as stupid as you can work out how to use a computer. said by Christian Graus in the Soapbox
-
Taka Muraoka wrote: Learning from your mistakes is all good and well but it's much smarter to learn from other people's mistakes. Then you don't have to make the mistakes even once! True Taka, but some mistakes can be such fun they are worth repeating. :-) There is always a communication problem when a technical person has to talk to a non technical person. Imagine a group of technicians being managed by a non-technician. The results are terrible, the techs are never supplied with the right tools, they are given tasks that are either impossible or worthless. There is room for SAs in our world but very few of them can communicate well with technical people. Taka Muraoka wrote: In other words, social, interpersonal issues rather than technical issues. Yes a lot of developers fail terribly here, however the management should put in place physical systems so this can be minimised. Too often I have seen management create a time-line for a project with no input from the developers etc. The social skills really are up to the managemnet to have and not the techs. Regardz Colin J Davies
Sonork ID 100.9197:Colin
Warning Link to the minion's animation, do not use. It's a real shame that people as stupid as you can work out how to use a computer. said by Christian Graus in the Soapbox
Colin Davies wrote: There is always a communication problem when a technical person has to talk to a non technical person. Problems here are typically caused because the devs are not talking to each other! :-) Colin Davies wrote: management should put in place physical systems so this can be minimised. Exactly. It is possible to put in processes that significantly improve results almost for free. There's a story I read in a book ages ago that I really like (Steve McConnell, IIRC). It's long but I'm bored, so here goes...
The author used to get his coffee from a shop around the corner and it was pretty awful coffee. There were two high-school girls working there and they obviously didn't care too much about the coffee they were making. Some days it would be too strong, sometimes too weak, and yes, sometimes it was drinkable. The place eventually closed down. In its place, another coffee shop opened under a new owner. This one, however, made really good coffee and you *knew* that whatever time you went in, you were going to get a great cup of coffee. Funny thing was, it was the *same* two girls working there making the coffee! The author did a bit of investigation and found out why. In the new place, the owner had marked a line about 2/3 of the way down each coffee pot and made a rule that whenever the coffee dropped below the line, the staff had to stop whatever they were doing and put a new pot on. That's it. Turns out that at the old place, if they were busy they would just drain each pot and of course, would need another one in a hurry so they would try to speed things up by putting in a little extra coffee beans to make it stronger and hence take less time to brew, or just start pouring from it a bit early, giving weak coffee. In other words, you never knew what you were going to get. But at the new place, that simple rule meant that you got consistent, good coffee each time. The point was that the new owner, having more experience, put in place a process that significantly improved the quality of the results that took no extra time (in fact, probably saved a bit of time) and had **nothing to do with the skill of the people actually doing the work**.I love this story :-)
Software is everything. It also sucks. Charles Fishman [^]
-
Hmmm... Interesting post :yikes: :-) Colin Davies wrote: They should be taken outside and dealt to It's not really the devs that are the cause of the problems. [edit] There are good devs and there are bad devs (i.e. inexperienced or less skillful) and there are devs in between. The trick is to manage the mix properly. Sure, there are people around that are so bad and/or disruptive that they need to be fired but there's no-one like that here. [/edit] Colin Davies wrote: And on a further note, managers that expect to be respected becaause they have a management job are morons. Respect should be gained and is not a right. Too true, in any area of life. Colin Davies wrote: Taka if enough of your co-workers feel the same way as you I suggest you revolt I'm a contractor here so I don't really have a personal stake in it. I just find it really depressing to see companies make the same mistakes over and over again. People who actually give a damn about what they do and want to do a good job can't because they're crippled by poor work practices and processes. Stuff that we, as an industry, should have surely learnt to know better about by now. Learning from your mistakes is all good and well but it's much smarter to learn from other people's mistakes. Then you don't have to make the mistakes even once! I had a long chat with someone recently about this kind of thing. The problem with technical people and things like this is that they think that the way to fix it is through technical solutions. Not realising that the *underlying* problems are caused by not understanding how people work, operate and communicate. In other words, social, interpersonal issues rather than technical issues.
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
Taka Muraoka wrote: Not realising that the *underlying* problems are caused by not understanding how people work, operate and communicate. In other words, social, interpersonal issues rather than technical issues. The problem though, is that often technical people ARE aware of the bigger issues, however they know they can't do anything about them. So what's the point of dwelling on these issues? Instead, focus on changing the things that they CAN change, and let the CEO appoint a management consultant to tell them about the people issues instead. Nobody listens to (or likes) a technical person that speaks up about managerial issues. Hey - if the techo knew so much, they'd be a manager. And this works the same in the other direction. How many developers like a manager telling them how to build something? This is not to say that the techo (or manager) doesn't have something valuable to add. Just that they're not likely to be listened to. Really though... I think I'll just focus on getting the daily task done, and let my passion for my work dissipate into triathlon training or something equally unproductive. (but infinitely more enjoyable) And they still ran faster and faster and faster, till they all just melted away, and there was nothing left but a great big pool of melted butter "I ask candidates to create an object model of a chicken." -Bruce Eckel
-
Hmmm... Interesting post :yikes: :-) Colin Davies wrote: They should be taken outside and dealt to It's not really the devs that are the cause of the problems. [edit] There are good devs and there are bad devs (i.e. inexperienced or less skillful) and there are devs in between. The trick is to manage the mix properly. Sure, there are people around that are so bad and/or disruptive that they need to be fired but there's no-one like that here. [/edit] Colin Davies wrote: And on a further note, managers that expect to be respected becaause they have a management job are morons. Respect should be gained and is not a right. Too true, in any area of life. Colin Davies wrote: Taka if enough of your co-workers feel the same way as you I suggest you revolt I'm a contractor here so I don't really have a personal stake in it. I just find it really depressing to see companies make the same mistakes over and over again. People who actually give a damn about what they do and want to do a good job can't because they're crippled by poor work practices and processes. Stuff that we, as an industry, should have surely learnt to know better about by now. Learning from your mistakes is all good and well but it's much smarter to learn from other people's mistakes. Then you don't have to make the mistakes even once! I had a long chat with someone recently about this kind of thing. The problem with technical people and things like this is that they think that the way to fix it is through technical solutions. Not realising that the *underlying* problems are caused by not understanding how people work, operate and communicate. In other words, social, interpersonal issues rather than technical issues.
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
Taka Muraoka wrote: Learning from your mistakes is all good and well but it's much smarter to learn from other people's mistakes. Then you don't have to make the mistakes even once! That's part of the reason I created www.latedecember.com - if only for my own learning! Good post Taka :-D Davy Blog for Software Testing, Bugs, Quality, Security and Stability - www.latedecember.com
News From Scotland - The Angus Blog and The Dundee Blog
My Personal Blog - Homepage. -
Taka Muraoka wrote: Not realising that the *underlying* problems are caused by not understanding how people work, operate and communicate. In other words, social, interpersonal issues rather than technical issues. The problem though, is that often technical people ARE aware of the bigger issues, however they know they can't do anything about them. So what's the point of dwelling on these issues? Instead, focus on changing the things that they CAN change, and let the CEO appoint a management consultant to tell them about the people issues instead. Nobody listens to (or likes) a technical person that speaks up about managerial issues. Hey - if the techo knew so much, they'd be a manager. And this works the same in the other direction. How many developers like a manager telling them how to build something? This is not to say that the techo (or manager) doesn't have something valuable to add. Just that they're not likely to be listened to. Really though... I think I'll just focus on getting the daily task done, and let my passion for my work dissipate into triathlon training or something equally unproductive. (but infinitely more enjoyable) And they still ran faster and faster and faster, till they all just melted away, and there was nothing left but a great big pool of melted butter "I ask candidates to create an object model of a chicken." -Bruce Eckel
Peter Hancock wrote: technical people ARE aware of the bigger issues, however they know they can't do anything about them. I would very much dispute that. Most techs aren't very good at the non-technical stuff. Peter Hancock wrote: Nobody listens to (or likes) a technical person that speaks up about managerial issues. The stuff I was talking about was not exclusively the province of managers. Development is much more than the process of writing code. Communication, for example, is one important part of it. So if a tech has something to say about poor communication within the group, this is not impinging on somebody else's territory - it is directly relevant to his task at hand. Anyway, so many problems stem from this divide between managers and developers that you suggest. Peter Hancock wrote: if the techo knew so much, they'd be a manager. Bullshit. There are plenty of technical people out there who are perfectly capable of managing but choose not to. Peter Hancock wrote: How many developers like a manager telling them how to build something? If the manager had a clue about what they were talking about, it wouldn't be so bad. And did it in the right way - most devs don't like even other devs telling them how to cut code!
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
-
Colin Davies wrote: There is always a communication problem when a technical person has to talk to a non technical person. Problems here are typically caused because the devs are not talking to each other! :-) Colin Davies wrote: management should put in place physical systems so this can be minimised. Exactly. It is possible to put in processes that significantly improve results almost for free. There's a story I read in a book ages ago that I really like (Steve McConnell, IIRC). It's long but I'm bored, so here goes...
The author used to get his coffee from a shop around the corner and it was pretty awful coffee. There were two high-school girls working there and they obviously didn't care too much about the coffee they were making. Some days it would be too strong, sometimes too weak, and yes, sometimes it was drinkable. The place eventually closed down. In its place, another coffee shop opened under a new owner. This one, however, made really good coffee and you *knew* that whatever time you went in, you were going to get a great cup of coffee. Funny thing was, it was the *same* two girls working there making the coffee! The author did a bit of investigation and found out why. In the new place, the owner had marked a line about 2/3 of the way down each coffee pot and made a rule that whenever the coffee dropped below the line, the staff had to stop whatever they were doing and put a new pot on. That's it. Turns out that at the old place, if they were busy they would just drain each pot and of course, would need another one in a hurry so they would try to speed things up by putting in a little extra coffee beans to make it stronger and hence take less time to brew, or just start pouring from it a bit early, giving weak coffee. In other words, you never knew what you were going to get. But at the new place, that simple rule meant that you got consistent, good coffee each time. The point was that the new owner, having more experience, put in place a process that significantly improved the quality of the results that took no extra time (in fact, probably saved a bit of time) and had **nothing to do with the skill of the people actually doing the work**.I love this story :-)
Software is everything. It also sucks. Charles Fishman [^]
:-D I like it! Taka Muraoka wrote: The point was that the new owner, having more experience, put in place a process that significantly improved the quality of the results that took no extra time (in fact, probably saved a bit of time) and had nothing to do with the skill of the people actually doing the work. However - this is still a "technical" solution - albeit very low tech. A measurement was made as to the level of coffee that should be used to change the pot, based on prior expertise and experience. technical a) Having special skill or practical knowledge especially in a mechanical or scientific field: a technical adviser. b) Used in or peculiar to a specific field or profession; specialized: technical terminology. And they still ran faster and faster and faster, till they all just melted away, and there was nothing left but a great big pool of melted butter "I ask candidates to create an object model of a chicken." -Bruce Eckel
-
Taka Muraoka wrote: 1:15 meeting (18 people * 1:15 = 22.5 man hours!) Excellent seeing someone else calculating how much these crud meetings cost! Lets say in your group of 18 that there were 5 devs who were the ones really holding the show up. They should be taken outside and dealt to! A bit more of this treatment and they would quickly change there habits or quit working for the company. Taka Muraoka wrote: about best practices and how to improve process, This talk is crud and only makes things worse. In my experience managers hold meetings principally to justify their reason for existing, not to improve anything. Any manager who holds regular meetings is an obvious failure as a manager. Management is not about stopping people from working through holding meetings, but is about getting people to do what the manager wants rather than they want. And on a further note, managers that expect to be respected becaause they have a management job are morons. Respect should be gained and is not a right. Taka if enough of your co-workers feel the same way as you I suggest you revolt, and write to the directors of the company to get your management structure changed. Don't scre around at the CEO level as he/she is also obviously incompetent as well! Regardz Colin J Davies
Sonork ID 100.9197:Colin
Warning Link to the minion's animation, do not use. It's a real shame that people as stupid as you can work out how to use a computer. said by Christian Graus in the Soapbox
Colin Davies wrote: In my experience managers hold meetings principally to justify their reason for existing, not to improve anything. 100 points, Bingo! This is the very sad truth, but even worse than managers and controlers are commercial counsellors... They make lets say, 10 days interviews, then they scribble (yes draw, not computer) a sketch on the overhead-projector and what's the soloution? We need more managers, and on the other hand, some workers and developpers have to go.... X| My question is sometimes, what do they want to manage in future, when everybody is fired??:confused: Wired (manager) world...
Olli Make it idiot proof and someone will make a better idiot......
:beer: + :java: = NULL :=> X| -
:-D I like it! Taka Muraoka wrote: The point was that the new owner, having more experience, put in place a process that significantly improved the quality of the results that took no extra time (in fact, probably saved a bit of time) and had nothing to do with the skill of the people actually doing the work. However - this is still a "technical" solution - albeit very low tech. A measurement was made as to the level of coffee that should be used to change the pot, based on prior expertise and experience. technical a) Having special skill or practical knowledge especially in a mechanical or scientific field: a technical adviser. b) Used in or peculiar to a specific field or profession; specialized: technical terminology. And they still ran faster and faster and faster, till they all just melted away, and there was nothing left but a great big pool of melted butter "I ask candidates to create an object model of a chicken." -Bruce Eckel
Peter Hancock wrote: However - this is still a "technical" solution No. Ultimately any solution that gets implemented will be "technical" in nature. But in this case, the solution had a non-technical origin. It recognized the fact that human nature being what it is, coffee pots will be drained until they are empty and then new pots will be hurriedly brewed to try catch up. The solution that the new manager came up with actually took the technical considerations out of the process. The girls no longer had to think about what they were doing, technically. All they had to do was follow the procedure and they would get good coffee every time. Taken to extremes, this gives you Big Macs, but there is still value in having processes that recognizes that 1) people are lazy and 2) people are dumb (including myself, on both counts :-() and tries to compensate for that.
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
-
Peter Hancock wrote: technical people ARE aware of the bigger issues, however they know they can't do anything about them. I would very much dispute that. Most techs aren't very good at the non-technical stuff. Peter Hancock wrote: Nobody listens to (or likes) a technical person that speaks up about managerial issues. The stuff I was talking about was not exclusively the province of managers. Development is much more than the process of writing code. Communication, for example, is one important part of it. So if a tech has something to say about poor communication within the group, this is not impinging on somebody else's territory - it is directly relevant to his task at hand. Anyway, so many problems stem from this divide between managers and developers that you suggest. Peter Hancock wrote: if the techo knew so much, they'd be a manager. Bullshit. There are plenty of technical people out there who are perfectly capable of managing but choose not to. Peter Hancock wrote: How many developers like a manager telling them how to build something? If the manager had a clue about what they were talking about, it wouldn't be so bad. And did it in the right way - most devs don't like even other devs telling them how to cut code!
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
Taka Muraoka wrote: I would very much dispute that. Most techs aren't very good at the non-technical stuff. and then you state Taka Muraoka wrote: Bullshit. There are plenty of technical people out there who are perfectly capable of managing but choose not to. You can't have it both ways. I agree with your second statement though... and my comment "if they knew so much, they'd be a manager" was said tongue in cheek. I shoulda put [sarcasm] around it. Taka Muraoka wrote: Anyway, so many problems stem from this divide between managers and developers that you suggest. With this - I agree wholeheartedly. And they still ran faster and faster and faster, till they all just melted away, and there was nothing left but a great big pool of melted butter "I ask candidates to create an object model of a chicken." -Bruce Eckel
-
Taka Muraoka wrote: I would very much dispute that. Most techs aren't very good at the non-technical stuff. and then you state Taka Muraoka wrote: Bullshit. There are plenty of technical people out there who are perfectly capable of managing but choose not to. You can't have it both ways. I agree with your second statement though... and my comment "if they knew so much, they'd be a manager" was said tongue in cheek. I shoulda put [sarcasm] around it. Taka Muraoka wrote: Anyway, so many problems stem from this divide between managers and developers that you suggest. With this - I agree wholeheartedly. And they still ran faster and faster and faster, till they all just melted away, and there was nothing left but a great big pool of melted butter "I ask candidates to create an object model of a chicken." -Bruce Eckel
Peter Hancock wrote: You can't have it both ways. Somehow, I had a feeling you would say that! :rolleyes: Of course I can have it both ways. "All developers" minus "most techs who aren't good at non-tech stuff" gives "the number of people who are perfectly capable of managing" (more or less). Given a sufficiently large "All developers", you can still have plenty of people in the "the number of people who are perfectly capable of managing" category.
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
-
Peter Hancock wrote: You can't have it both ways. Somehow, I had a feeling you would say that! :rolleyes: Of course I can have it both ways. "All developers" minus "most techs who aren't good at non-tech stuff" gives "the number of people who are perfectly capable of managing" (more or less). Given a sufficiently large "All developers", you can still have plenty of people in the "the number of people who are perfectly capable of managing" category.
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
That's funny.;P:-D And they still ran faster and faster and faster, till they all just melted away, and there was nothing left but a great big pool of melted butter "I ask candidates to create an object model of a chicken." -Bruce Eckel
-
After having just sat through a 1:15 meeting (18 people * 1:15 = 22.5 man hours!) listening to people going around and around in circles about best practices and how to improve process, making the same mistakes that just about every other company that ever existed has also already made. I might just go back to Thailand and become a monk (I'm not kidding!). Maybe I could be called Phra l33t :-) Problem is, I really love developing :(( /end_rant
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
Poor Taka! Seriuosly, dude, why don't you come over to India? You were telling me that sometime back, remember? You see, Venkat or somebody told me that here in India, even VB developers (do I see a contradiction there? ) are paid nice salaries. Now don't hold it against me if you come here and find your salary too low :) - I'm just repeating what Venkat told me. Taka Muraoka wrote: Problem is, I really love developing Uh oh, I see a problem... (with VB, I mean) :) Seriously, my sympathies... and :rose: Vikram. ----------------------------- 1. Don't ask unnecessary questions. You know what I mean? 2. Avoid redundancy at all costs. 3. Avoid redundancy at all costs. "Do not give redundant error messages again and again." - A classmate of mine, while giving a class talk on error detection in compiler design.
-
Poor Taka! Seriuosly, dude, why don't you come over to India? You were telling me that sometime back, remember? You see, Venkat or somebody told me that here in India, even VB developers (do I see a contradiction there? ) are paid nice salaries. Now don't hold it against me if you come here and find your salary too low :) - I'm just repeating what Venkat told me. Taka Muraoka wrote: Problem is, I really love developing Uh oh, I see a problem... (with VB, I mean) :) Seriously, my sympathies... and :rose: Vikram. ----------------------------- 1. Don't ask unnecessary questions. You know what I mean? 2. Avoid redundancy at all costs. 3. Avoid redundancy at all costs. "Do not give redundant error messages again and again." - A classmate of mine, while giving a class talk on error detection in compiler design.
Vikram Punathambekar wrote: Seriuosly, dude, why don't you come over to India? Don't tempt me! Know any good monasteries? :-)
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
-
Vikram Punathambekar wrote: Seriuosly, dude, why don't you come over to India? Don't tempt me! Know any good monasteries? :-)
Software is everything. It also sucks. Charles Fishman [^] Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
Taka Muraoka wrote: Don't tempt me! Come to India, come to India, come to India... Taka Muraoka wrote: Know any good monasteries? You're kidding, aren't you? If not, sorry- there are no monasteries down South that I know of ( I don't think there are any, anyway). You'll find a lot in North India, though. The states in which Buddhism is prevalent are Sikkim (predominant), J&K (Ladakh), Himachal Pradesh, UP, Uttaranchal and some parts of Bihar and the NE. Of course, there's Dharmashala in HP, where His Holiness the Dalai Lama lives; and Gaya in Bihar where the Buddha attained enlightenment. No, I'm not a Buddhist. Vikram. ----------------------------- 1. Don't ask unnecessary questions. You know what I mean? 2. Avoid redundancy at all costs. 3. Avoid redundancy at all costs. "Do not give redundant error messages again and again." - A classmate of mine, while giving a class talk on error detection in compiler design.