Your job is not to write code?
-
[^]
Bad things happen when I try to think freely and that "your job is not to write code" Love the article.
-
[^]
Writing code seems to be on the wane - it's all about fighting with the tools these days
-
You are the lucky one - you just finishing your studies and already aware that your job will not be to write code...See us poor fellows who wrote code for 20+ years just to reveal we done it all wrong...What a waste of time!
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V) תפסיק לספר לה' כמה הצרות שלך גדולות, תספר לצרות שלך כמה ה' גדול!
I feel for you mates, glad i registered here at right time in the right place :cool:
if(this.signature != "") { MessageBox.Show("This is my signature: " + Environment.NewLine + signature); } else { MessageBox.Show("404-Signature not found"); }
-
Writing code seems to be on the wane - it's all about fighting with the tools these days
RugbyLeague wrote:
it's all about fighting with the tools these days
Nah...we've been doing that for years!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
[^]
She has it all wrong! Figuring out what users want and need is her job (or my boss'). Implementing it (yes, writing the code!) is my job. If what I make is not what the users want it's her fault for not specifying it well enough (well, could still be my fault if I didn't read her specs thoroughly). If what I make does not work, creates wrong output, is buggy, etc. then, yes, it's a code issue and I am to blame. It's easy to say everything is the programmers fault... Unless she wants some well paid and talented engineers with low social skills to talk to users. Yeah, real good use of resources...
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
} -
RugbyLeague wrote:
it's all about fighting with the tools these days
Nah...we've been doing that for years!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
It all seems to be deployment stuff these days
-
She has it all wrong! Figuring out what users want and need is her job (or my boss'). Implementing it (yes, writing the code!) is my job. If what I make is not what the users want it's her fault for not specifying it well enough (well, could still be my fault if I didn't read her specs thoroughly). If what I make does not work, creates wrong output, is buggy, etc. then, yes, it's a code issue and I am to blame. It's easy to say everything is the programmers fault... Unless she wants some well paid and talented engineers with low social skills to talk to users. Yeah, real good use of resources...
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}Bah, you have it easy... Figuring out what users want is MY job. Figuring out what users WILL probably want a few years from now, is also MY job. Designing it is MY job. Coding it is MY job. Testing it is MY job. Deploying it is MY job. Man, sometimes being a solo developer is a pain... But hey, fortunately keeping the computers and networks running is someone else's job... Small favors, I suppose.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
[^]
-
[^]
I understand the first reactions of the posters above, but she does have a point. It, of course, depends on your job. If you are a code grinder, your job is to write code. She mentions "Engineers", a term I don't believe applies to code grinders! Of course many of us here (most?) are a lot more than code grinders. Perhaps the term still applies to newbs who have just graduated a programming course. One key point is that most of us in a programming career are technophiles. We love to get our hands on the new stuff and experiment with new techniques. Wonderful! but we have to remember that our end users may not have access to this new stuff. Put it another way: You don't often hear about how wonderful the graphics are in the new accounting package. The bottom line for businesses is the bottom line. If you're working for a business that sells software, the "whiziness" of the software is secondary to the functionality and how well it sells is paramount. If you are providing tools in a business that sells anything else, your role is to build tools that improve efficiency, facilitate better management decisions and generally make your coworkers lives better. Of course, we all know that, but it doesn't hurt to be reminded once in a while!
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
-
Bah, you have it easy... Figuring out what users want is MY job. Figuring out what users WILL probably want a few years from now, is also MY job. Designing it is MY job. Coding it is MY job. Testing it is MY job. Deploying it is MY job. Man, sometimes being a solo developer is a pain... But hey, fortunately keeping the computers and networks running is someone else's job... Small favors, I suppose.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)I find myself in the same position as you although I do have a junior developer under my wing too. I prefer having contact with the users occasionally as I can usually ask the questions that others won't ask such as "are you sure you want it to blow up in your face every time you use it?" However despite being a project manager, business analyst, developer and mentor I only get paid the meagre developer salary - note to self, must ask for a raise...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
I find myself in the same position as you although I do have a junior developer under my wing too. I prefer having contact with the users occasionally as I can usually ask the questions that others won't ask such as "are you sure you want it to blow up in your face every time you use it?" However despite being a project manager, business analyst, developer and mentor I only get paid the meagre developer salary - note to self, must ask for a raise...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
GuyThiebaut wrote:
I prefer having contact with the users occasionally
Uh, yeah... I sit on the same trading desk as my users... I turn my head ninety degrees to the right, and I can see all of them... Sometimes, that's a good thing. Sometimes, I want to go find some cardboard boxes to stack up in between them and me :-D
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
I understand the first reactions of the posters above, but she does have a point. It, of course, depends on your job. If you are a code grinder, your job is to write code. She mentions "Engineers", a term I don't believe applies to code grinders! Of course many of us here (most?) are a lot more than code grinders. Perhaps the term still applies to newbs who have just graduated a programming course. One key point is that most of us in a programming career are technophiles. We love to get our hands on the new stuff and experiment with new techniques. Wonderful! but we have to remember that our end users may not have access to this new stuff. Put it another way: You don't often hear about how wonderful the graphics are in the new accounting package. The bottom line for businesses is the bottom line. If you're working for a business that sells software, the "whiziness" of the software is secondary to the functionality and how well it sells is paramount. If you are providing tools in a business that sells anything else, your role is to build tools that improve efficiency, facilitate better management decisions and generally make your coworkers lives better. Of course, we all know that, but it doesn't hurt to be reminded once in a while!
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
I spent a year writing an ERP system that does everything from sales prospects to invoicing. In the yearly, what we have done, presentation to the director, all he commented on was the nice Excel pie-chart I had created that shows what I have been working on. I call it the Apple generation - people assume your systems will work perfectly and when they do will only then only notice the pretty graphics(forget the year of extra hours and sweating over creating systems nobody is able to specify for you, that you somehow magically guess into being for them).
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
I spent a year writing an ERP system that does everything from sales prospects to invoicing. In the yearly, what we have done, presentation to the director, all he commented on was the nice Excel pie-chart I had created that shows what I have been working on. I call it the Apple generation - people assume your systems will work perfectly and when they do will only then only notice the pretty graphics(forget the year of extra hours and sweating over creating systems nobody is able to specify for you, that you somehow magically guess into being for them).
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
... and yet MS Dynamics sells very well! :)
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
-
... and yet MS Dynamics sells very well! :)
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
You must be psychic because that appears to be the future... :(
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
You must be psychic because that appears to be the future... :(
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
Damn, you're revealed my secret power!
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
-
[^]
Meh. I dunno. This misses the mark in the interest of saying something clever sounding. Yeah yeah, a programmer's job isn't to write code any more than a manager's job is to run meetings. Our GOAL is to improve the product for the customer. Writing code is our primary mechanism for doing that.
-
GuyThiebaut wrote:
I prefer having contact with the users occasionally
Uh, yeah... I sit on the same trading desk as my users... I turn my head ninety degrees to the right, and I can see all of them... Sometimes, that's a good thing. Sometimes, I want to go find some cardboard boxes to stack up in between them and me :-D
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Easily the best way to get honest feedback when they forget you're there though. Part of me wants to be a coder cog in the big machine just to see what it feels like when you aren't responsible for the entire process. I'm guessing it's just soul crushing in a different way.
-
[^]
Push your code. Get it into production. Then run it and check it.^I somehow missed that gem on first scan. Case of incompetent management run amok asking the programmers to do the management's job and at the same time trying to tell programmers how to code. We are all doomed! ;P -
I understand the first reactions of the posters above, but she does have a point. It, of course, depends on your job. If you are a code grinder, your job is to write code. She mentions "Engineers", a term I don't believe applies to code grinders! Of course many of us here (most?) are a lot more than code grinders. Perhaps the term still applies to newbs who have just graduated a programming course. One key point is that most of us in a programming career are technophiles. We love to get our hands on the new stuff and experiment with new techniques. Wonderful! but we have to remember that our end users may not have access to this new stuff. Put it another way: You don't often hear about how wonderful the graphics are in the new accounting package. The bottom line for businesses is the bottom line. If you're working for a business that sells software, the "whiziness" of the software is secondary to the functionality and how well it sells is paramount. If you are providing tools in a business that sells anything else, your role is to build tools that improve efficiency, facilitate better management decisions and generally make your coworkers lives better. Of course, we all know that, but it doesn't hurt to be reminded once in a while!
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
PhilLenoir wrote:
"Engineers", a term I don't believe applies
Nor to most developers. Developing Operating Systems, Missile Control Systems, Compilers and IDEs, might be engineers, but developing enterprise/line-of-business apps just isn't engineering.
-
Writing code seems to be on the wane - it's all about fighting with the tools these days
To further that point, I see too much effort spent on looking for tools and then trying to get them to work, rather than simply writing exactly what you need.
