|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
Which is so often what happens anyway when you end up ditching the tools in favour of the deadline and your income.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
|
|
|
|
|
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...
My blog[ ^]
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.
|
|
|
|
|
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 
|
|
|
|
|
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.
|
|
|
|
|
Ian - yes it is a pain. I think I have two dozen hats at my office. Current one I have on now is "beat me, I can take it". Sort of stuck in an analysis rut....
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Well, I actually talk a lot to the customer too (not the actual users).
And I also know that what they say is not always what they want.
But my strength lies in coding and that's what my boss wants me to do as much as possible.
I just think saying everything is our responsibility is a bit off.
Well, maybe not in your case, but getting software to the customer is more often than not (I think) a joint effort.
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
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
|
|
|
|
|
... 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
|
|
|
|
|
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.
|
|
|
|
|
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.
modified 10-Nov-14 11:06am.
|
|
|
|
|
I loved that article. It definitely reflects my view of software development. There's a HUGE difference between coders and engineers. My job is to make the user experience better, make their lives easier, improve efficiency, make better business decisions and ultimately save $$$ at the end of the day. I'm often doing QA, marketing, customer/technical support, engineering, operations, DevOps, system administration - sometimes all in the same day!
It doesn't matter how "cool" your code is - if it's crap and the user doesn't like it, then you have a serious problem. Too many "engineers" (note the quotation marks) like using the latest toys without realizing what problems those impose on their users when it comes down to deployment and maintenance. Those are by far the biggest headaches and they're often unprepared for the influx of questions, bugs and complaints from users.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
-- Marcus Brigstocke, British Comedian
|
|
|
|
|
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.
|
|
|
|
|
Now, seriously, what's her job, then ?
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Entropy isn't what it used to.
|
|
|
|
|
|
Translation of linked article: "I know best what your elephanting job is, so shut up !"
« I am putting myself to the fullest possible use which is all, I think, that any conscious entity can ever hope to do » HAL (Heuristically programmed ALgorithmic computer) in "2001, A Space Odyssey"
|
|
|
|
|
(Classic Cryptic Crossword Clue)
Since DD is likely to be unavailable until mid May, and I can't write good crossword clues to save my life: here is a classic one, just to keep the grey cells ticking over.
GEGS! (9, 4)
Fans of departed donkeys will remember this! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
