Comment by Scandiravian | Hacker News Reader

Comment by Scandiravian | Hacker News Reader

Parent Full thread

- Communication skills

Being able to clearly explain why your solution will solve a given problem better than the alternative and listen to your colleagues when their suggestion is better than yours, will save you an incredible amount of frustration. It is in my opinion the most important skill I have learned

- Asking why when debugging

Finding the code that's causing a bug is only the first step. The next is preventing a similar one happening again. By constantly asking "why was this choice made", you end up finding the actual weak points in both the code and your process. Whether it's because a hack some other place forced you to write another hack, that then failed or because there was a deadline so the commit was made at 3am, there is an important lesson to be had. If you combine that with good communication, you can talk to the team about changing things, so you avoid creating similar bugs in the future. (Pro-tip: 99% of bugs are there because there wasn't time to do things better)

I don't know the sense of OP, but there's a difference between 'programming' and 'software development'--the latter is done in a team. Often the terms are used interchangeably but the skills to make one a good solo software writer only overlap with developing in a group.

I intended it to be pretty open ended. Mostly interested in skills that are useful for _both_ solo and team work. I agree that there are some things that can be very useful for team work that are not as essential for solo work when it comes to programming. For example, being able to justify technical decisions to higher ups. Lots of communication skills are essential for teamwork.

The examples I gave obviously requires being part of a team, but even programming on your own, I think it's one of the most important skills.

I'd be happy to elaborate on that argument if you have any examples of one or more situations where you wouldn't consider communication important? :)

I totally agree - I think I'm probably coming off as disagreeing with you though.

I think the difference for me is that the importance of communication for solo programming is a bit of a sliding scale depending on what your goals are. There aren't many exceptions when you work on a team. When I use the word importance, I'm tying it to a notion of necessity in relation to some goal. Team goals trump individual goals in organizations.

if you have no intention of making your code available for someone else to read / use / modify, the benefit for having readable code is really for yourself in six months and nobody else.

you also don't need to tell anyone what you're doing, so being able to clearly / succinctly explain what it is and why it's useful isn't a necessity. Does that make it an unimportant skill? No, it's just that the goals are different

I would extend the term "communication" to also include how we speak and listen to ourselves

I don't think I am able to explain it clearly without writing a very long post. There's a really good book by Marshal Rosenberg, titled non-violent communication, which gives a better explanation than I can right now. I would recommend it to pretty much anyone, if only for the very healthy way of treating oneself that it provides. Mileage may vary, but it fits my mental model pretty well

As an aside, I'm very glad to read through the replies to your post and see all the constructive you've engaged in. I've gotten mare than a few new thoughts and ideas because I chose to get involved in this post - thank you :)

Ah, I see. Thank you for clarifying that. That book sounds interesting, I'll check it out.

Thanks for taking the time to engage! I've also learned quite a bit reading through everyone's responses.

I agree with the difference between programming and software development, though I'm not entirely sure on why you're pointing this difference out. Do you think my answer is not answering the OP's question? :)

>99% of bugs are there because there wasn't time to do things better

For a very narrow definition of 'better', maybe. I'd argue most bugs are there because the cost of a bug is less than the cost of developer time it's take to prevent such bugs. There are industries where the cost of a bug is very high, but mostly bugs are like unemploymency rates: it's almost never economically feasible to get them down to zero.

I think we're saying the same thing in two different ways, so I agree with your point. What I'm reading is a good "why" - why wasn't there time to prevent this bug.

Better is a subjective word, so I think I could have made my point more clear by instead writing "99% of bugs are there because there wasn't allocated enough time to prevent them"

Do you agree more with that statement than the one I originally posted? :)

> I'd argue most bugs are there because the cost of a bug is less than the cost of developer time

You make it seem more planned and reasoned out than it really is. I mean, you can make a meta-argument, that market evolution and pressures push things towards that optimal cost-benefit spot, but on the micro scale it often just happenstance.

Again, the meta-argument can be that even doing the cost-benefit analysis is not worth the cost, but it's quite handwavy.

What counts as "better" anyway? From the engineering perspective it's about efficiency, bug-freeness, elegance. From the company perspective, profits. From the manager perspective, looking good and getting promoted.

You can often game the system by rushing a subpar product out the door, downplaying and not even caring about the defects, wooing customers into buying in with clever sales tactics and marketing, then moving on before things start crumbling down. In some sense this was worth it in terms of your personal costs and benefits and all was done in the best possible way.

Reply on news.ycombinator.com