Hacker News Reader

Comment by munk-a | Hacker News Reader

As someone who's worked a fair bit now - coding has absolutely no value to any company. What delivers results is deploying solutions - whether those solutions are powered by hotpockets and red bull at 3AM or whether they are entirely composed of meetings discussing how to inform customers of the change - it is never "coding" that solves a problem. "Coding" is at most the effort of transcribing a solution from your brain to a computer - most devs will iterate over several drafts during this process. If, instead, you iterate drafts on paper and then just type up the solution when you're happy with it - it makes no difference - you've still delivered the solution.

The author is conflating coding with solution planning in a pretty minor way - you're more seriously conflating coding with solution building.

View on HN

> As someone who's worked a fair bit now - coding has absolutely no value to any company. What delivers results is deploying solutions...

I don't see how some solutions not requiring code means that coding is not valuable, as some solutions evidently do require code.

When the solution requires code, the code is the solution, whether it's written in pseudo code or a language. I don't think there is a line separating the two. Just like language is thought.

Your "deploying solutions" could be replaced with "deploying code" (whether created in house or third party).

If your solution depends on code, then the quality of that code will also be important, which will include aesthetics, design, readability, tests.

In the long run, this is valuable, as you can't regularly and reliably ship the solution, unless you're confident it still works.

Coding often gives feedback on your plan and design. You may not see its flaws as long as its only in your head or on paper. When you write the code and try to run it on your computer you often realize something is wrong with it.

Architects do a similar thing, they visualize in their heads and on paper, but then they also actually build 3D small-scale prototypes to get feedback on their design.

So I would say that coding can also be an important part of the design process. It is not just transliterating what's in your head to code-files on the computer, it can help improve the design which is in your brain.

this is why I made the question about coding being called 'typing', in writing, coding or anything similar when you are at the 'typing' stage you will often revise and think more about what you are doing, add in conditions for edge cases and so forth. It is not just transcribing the thoughts you have already had, it is developing those thoughts at the same time.

That is an important point I believe. code is more concrete than plain thoughts, and concrete things give us better feedback than abstract ideas

I seem to keep reading what appears to be this nugget of wisdom about building solutions rather than coding but I can't tell if I'm missing something or if I just consider the distinction to be sort of obvious. Can you please help explain? My reasoning is as follows.

So if you're a programmer then you're in the business of building software solutions which are generally built via writing code or script of some sort.

If the problem is best solved via a method other than writing software, then that's great. Not every problem needs software. Not every problem even needs solving either.

If however the problem does need a software solution then it's obvious that you should make sure you actually understand the problem so that you actually solve it.

I guess I just don't see how coding isn't equivalent to solution building unless what you call coding I call typing. For me thinking, researching, investigating, designing, engineering, planning, and even just "sleeping on it" are all part of the coding process.

I suppose that if the purpose of your coding is to learn or play then you might not be building a solution.

Is this just semantics or am I missing something?

> The author is conflating coding with solution planning in a pretty minor way - you're more seriously conflating coding with solution building.

I don't think so, or perhaps expressed myself poorly. Planning is a critical part of solution building. Coding is putting the pieces together.

Unless you're absolutely winging it, you're mostly doing planning and then execution. My argument is the planning - the most important part of solution building - is what's being done on paper.

if what you say is correct in all cases then why do we not just call coding 'typing'?

Like another commenter said, it’s probably just semantics, but in software most don’t share a common educational background and language. The SDLC [1] is used where I work and coding / typing is called development. It’s where the actual code is written.

I think it’s always true that there is some time spent figuring out what problem is being solved, what needs to be built to solve the problem, building something, and making sure that it solves the original problem.

In mechanical or electronics it tends to be called manufacturing instead of development. In civil engineering or architecture it tends to be called construction instead of development. I think the difference in creating software is that one person can do all phases. They can even do the phases without formally documenting anything. The phases can be much shorter and iterated on much quicker in some software projects. I think when the software projects become larger and require more developers that they tend to have a more clear demarcation between phases and use more formality in documentation.

I think it would be more beneficial to the software industry if everyone was working with similar enough terminology that discussions don’t end up revolving around who is operating under what definition and which definition is best. But at the end of the day that’s just my opinion.

Reply on news.ycombinator.com