Hacker News Reader

Comment by edw519 | Hacker News Reader

I have always strongly believed that "Tech skills make you good. Other skills make you better."

OP brings up a lot of good points (who could argue with these), but overlooks my #1 fundamental: If you can't write good code, not much else matters.

I know lots of programmers who have mastered the technical skills but are weak at the other things, so no one would ever mistake them for "senior", no matter how good their code is.

But I know many more "I.T. people" who are good at the "soft stuff" (analysis, design, product ownership, people management, agile, etc.) but can't code. I don't want to sound snarky, but these people are a dime a dozen. They often have great attention to detail and patience, but would you really entrust them to build your software?

Learn how to build software first. Be able to do that well before adding the soft skills.

That's the most important software dev skill needed. And it is most definitely "technical".

View on HN

> If you can't write good code, not much else matters.

Can't stress this enough and I frankly don't understand all these articles claiming otherwise, when even the most minimal reflection would clear things up in a jiffy:

Take a skilled trapeze artist who has great attention to detail (I hope) and is patient (I hope) but cannot code.

Alternatively take a brilliant software developer who is slightly sloppy and not very patient.

Which one do you want writing your software?

Of course, that's accepting that these are important skills/attributes. I don't actually agree they are. See

https://medium.com/@petecam/why-laziness-impatience-and-hubr...

I agree that good code matters but I am not sure if it matters THAT much in some cases.

I write average code but always seek to make improvements. I'm always trying to improve my knowledge on OOP and learn about different approaches to architecture but at my company I could write garbage code and nobody would care. Recently, I tried to make an update to a legacy software and the code was quite bad, methods that were 15K lines long. Terrible variable names, UI elements named button1, button2 etc. However, nobody cared because it worked, it served it's purpose for the last 12 years, and yes it needs a complete rewrite, but it would probably need that anyway after 12 years as there are some major business changes.

I think every programmer should try to make things and try to improve. However, over-engineering and writing too many unit tests can also be a waste of time.

> over-engineering

Not sure why you think "great code" = "overengineering".

Great code is not overengineered, by definition.

So you write great code. Does your great code solve the customers problem? Were you even able to help the customer articulate the problem that needed solving?

Most software is written as a team nowadays. You may write great code, but how does it fit into what your entire is team is doing? Does your great code multiply the teams effectiveness?

You may have guessed it by now, but IMO for most cases communication is the first required skill, and then everything else. Obviously it's not the only required skill, but for me, communications importance cannot be understated.

> Does your great code solve the customers problem?

To me, "solving the customer's problem" is part of the definition of great code. Not sure what definition of "great code" would not involve that.

And again, we are talking software. So you have an awesome communicator who cannot code (and can't delegate...). Versus a so-so communicator who can code. No contest.

> I don't want to sound snarky, but these people are a dime a dozen.

Maybe this is influenced by geolocation or other factors, but IME actually competent "soft stuff" people are rarer than competent engineers.

We’ve already seen a fairly consistent trend - high performing / good companies allow failure but do not tolerate incompetence. The bar for competency in software as an industry and profession is all over the place. Most white collar professions have some forms of basic competency that’s somewhat objective where interviews are almost entirely about the soft parts as a result. Meanwhile, most of us are grinding leetcode and Hackerrank...

> Learn how to build software first. Be able to do that well before adding the soft skills.

We are all people before we are programmers, so I'd argue it makes sense to build people skills before programming skills :)

But I'm probably misinterpreting you.

Reply on news.ycombinator.com