Your Job is Not to Code | Hacker News Reader

Your Job is Not to Code

andresosinski.com

43 pointsDaishiman20 comments

"Your job is not to Code"...."Your job is to solve problems" says the post

Now that it is #1 on the front page, I look forward to the sequel "Your job is not to solve problems, your job is to prevent problems from happening in the first place"

Anyway, on a more serious note, my job is to code, my job also includes numerous other things. None of these things are necessarily an end to themselves, but semantic games aside, it is my job to do all of these things.

I guess I'm the only one so far who kinda agrees with the author.

One thing not explicitly spelled out in the article: you should avoid doing coding that is not actually solving anyone's problem.

I've seen a lot of engineers, and worse yet managers, who fall into the trap of "more typing = more productivity".

It's not that we're not agreeing, but think about it.

You can react to an article in three primary ways: agree, disagree, or learn.

It's easy to write articles everyone agrees or disagrees with. But that's like empty calories. Instant disagreement typically means the author is clueless. Instant agreement means the author is preaching to the choir. It's harder to write articles people learn from. And I don't think there's much to learn from that one.

Sometimes it's very hard to justify why a project needs to be done especially if it involves back-end refactoring. Additionally, there are many ways to implement a project; the fastest ways usually involves a lot of un-maintanable hacks. However, your project stakeholders won't care how terrible your code is as long as the project works

If it was up to business, they would have developers crank out features non-stop without time to go back and clean up technical debt.

The root cause is management not understanding how software development works.

Absolutely. I can't agree with this more.

A long time ago I worked on a codebase where (among other problems) developers who wanted to extend a particular feature needed to modify five or six different methods spread across a number of files. (This feature was basically a pipeline that took in JSON from our servers and translated it into views to display to the end user.) Forgetting to modify even one of these files would lead to code that compiled but would throw cryptic errors at runtime.

Developers from outside our team who wanted to work on the codebase and extend the feature would reliably lose several days to either the problem I described above, or hunting around the code trying to piece together how the feature worked from the disparate implementation details.

Eventually, I took some time off and refactored part of the feature so that only a single source of truth needed to be modified in order to extend it. As a bonus, this refactoring made the mapping between data models and views in our application explicit, making the behavior of the feature significantly easier to understand. I didn't ask management or submit any sort of formal proposal; I did this on my own time because I had become fed up with the limitations of the existing approach.

After the refactor entered the codebase, the aforementioned bugs vanished, as did many of the questions from outside developers about what models corresponded to which views, or how the feature worked, or how to extend the feature in general.

I tell this intentionally vague (and honestly quite pedestrian) anecdote not to brag (the refactor was reasonably straightforward), but rather because I wanted to emphasize the difference between feature work and technical-debt-payoff work. The refactor almost certainly saved a considerable amount of developer effort and increased code reliability. But how much so is not something that can be easily measured (if at all), unlike the impact of a user-facing feature. Not only this, some combination of apathy and political pressure from external stakeholders tends to lead management to deprioritize paying off technical debt. Proposals to management to formally set aside time to address other issues of similar scope were pushed back repeatedly or dropped.

PMs and product people can A/B test, gather analytics, get concrete data on hypothesis A versus hypothesis B when it comes to features. But it's rare that engineers get asked how much more quickly they could get their work done if they hadn't had to hack around unmaintainable hacks, or how much more reliable their code would be if bad design didn't muddy up the codebase or provide hiding spots for weird corner cases. Given how expensive software engineers are and how supposedly scarce they are, I'm honestly surprised that this isn't something management thinks about more.

Managers who don't know how to measure what they want settle for wanting what they can measure. Feature delivery is easy to measure, technical debt is hard to measure. Ofcourse, in the long run technical debt affects feature delivery, but people tend to look for causality relationships in the short term. That a decision not to allow refactoring slows down a set of features 6 months later won't be linked in a causality relationship unless proper root cause analysis is done.

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?

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

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).

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.

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.

The title is just linkbait. Coding is as much a means to solving a problem as walking is to getting to a destination.

Likewise, if someone is paying you to reach a destination, it is natural they'd care more that you reach the destination & on time, not so much about various aspects of walking style, quality of walking, how your walking gives you meaning in life, etc.

I'm 23 years old, and I'm a decent developer. Not the best by far, and have so much more to learn... but I command a very respectable salary for my experience, age, and location. I can do that because prior (and parallel) to being a software developer, I was a very very good salesperson (#1 for a company across their 250 stores, selling mobile phone contracts, retail not telesales). I'm super thankful for having done that (although the reasons I ended up doing that instead of development was not so nice), and I find it helps me every single day as a developer; dealing with clients, working with project managers, heck even negotiating my salary: all of these were made easier by my learning how to sell. I highly recommend learning it, sure it's not glamorous, but it is intellectually stimulating, albeit in a very different way to software engineering. That's my $0.02AUD anyway

"Your job is to solve problems" - This statement may be useful as a reminder, but most of the case - it is too obvious to gain something from it. What on earth are the jobs without solving problems? Of course understanding the problem is important, but still our primary goal is to code efficiently.

Code is for humans. The machines only understand pulses of electrons. Your job is not to code, your job is to make machines do things. Code is just your means of communication with the machines. It's the tool, not the job itself.

Though the job description certainly has requirements for how to code. And knowing a common language allows quick and efficient collaboration among your team members. So I'd say it is your job to know how to code in order to solve a problem that the business has.

Yes, but details like common language, coding style, etc are all rules that humans have made up in order to aid communication with other humans. They are part of the job only insofar as you need to work together with other humans. The machine does not know or care about those things at all.

It looks like the job of this article's writer is to create lots of bullshit.

> Pitch shamelessly

And link-bait shamelessly as well.

Yeah yeah yeah, as a garbage man, my job isn't to mop the floor and throw garbage out, it's to interact with people, educate them about proper recycling, tell them about the layout of the trash bins and how to locate the nearest one in case of emergency. Throwing garbage is not what we're being paid for. Garbage men are thought leaders, influencers, communicators and teachers.

Reply on news.ycombinator.com