31 ms·

I read this article twice and really don't understand what it was trying to say. From what little I gathered the author believes that it is more important to e

I read this article twice and really don't understand what it was trying to say. From what little I gathered the author believes that it is more important to educate the customer about what software developers do than to code? Or that our job is solving problems, not coding? (which if you are a software engineer, solving problems and coding go hand in hand). But then he conflates software engineering with IT. Can someone explain this to me?

dm2 12y ago
Some blog posts are just written because the author wanted an article to attract people to their site. I'm not necessarily saying that was the case with this article, but I do agree that it lacks substance, purpose, and a clear message. Some people are code monkeys, but many software developers (especially consultants) are fortunate enough to be primarily problem solvers. There is certainly a degree of creativity required for programming, you have to be able to think outside of the box, approach the problem from several prospectives, and it requires a wide range of skills and experience to produce a good solution. Sometimes it's even necessary to throw everything away and start over, just like an artist. Many professionals are problem solvers, lawyers, engineers, architects, soldiers, etc. Also, "How to Rant your Way Into the Front Page" by the same blog author and HN user, http://www.andresosinski.com.ar/blog_view_entry?id=4 http://www.andresosinski.com.ar/blog_view_entry?id=4 The problem is not that people are submitting these articles, it's that a huge number of people upvote it to #1 just because of the title (speculation on my part).
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
  - deleted 12y ago
    [deleted]
zachrose 12y ago
I can try. I think the author is saying that developers should go beyond "implementing the solution." Take time to understand the real problem at hand. Explain what you're trying to do, even if it doesn't work out. Push back when you're being asked for things that aren't realistic. This is basic, solid advice for anyone. It's also shares the same goals with most software engineering methods or meta-technologies: Scrum, BDD, user stories, etc.
slavik81 12y ago
Part of what they're trying to say that by understanding your customer's business, you can help build them better software. Rather than blindly implementing features you don't understand, you find out the underlying reason for the request. If there is a cheaper or more effective way to accomplish that goal you can suggest it to your customer.

dm2 12y ago

Some blog posts are just written because the author wanted an article to attract people to their site. I'm not necessarily saying that was the case with this article, but I do agree that it lacks substance, purpose, and a clear message. Some people are code monkeys, but many software developers (especially consultants) are fortunate enough to be primarily problem solvers. There is certainly a degree of creativity required for programming, you have to be able to think outside of the box, approach the problem from several prospectives, and it requires a wide range of skills and experience to produce a good solution. Sometimes it's even necessary to throw everything away and start over, just like an artist. Many professionals are problem solvers, lawyers, engineers, architects, soldiers, etc. Also, "How to Rant your Way Into the Front Page" by the same blog author and HN user, http://www.andresosinski.com.ar/blog_view_entry?id=4 http://www.andresosinski.com.ar/blog_view_entry?id=4 The problem is not that people are submitting these articles, it's that a huge number of people upvote it to #1 just because of the title (speculation on my part).

deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
- deleted 12y ago
  [deleted]

zachrose 12y ago

I can try. I think the author is saying that developers should go beyond "implementing the solution." Take time to understand the real problem at hand. Explain what you're trying to do, even if it doesn't work out. Push back when you're being asked for things that aren't realistic. This is basic, solid advice for anyone. It's also shares the same goals with most software engineering methods or meta-technologies: Scrum, BDD, user stories, etc.

slavik81 12y ago

Part of what they're trying to say that by understanding your customer's business, you can help build them better software. Rather than blindly implementing features you don't understand, you find out the underlying reason for the request. If there is a cheaper or more effective way to accomplish that goal you can suggest it to your customer.