Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Hard Thing About Software Development

linkedin.com

Post reply on HN
Print view View original

71–80 of 105 posts

Re: The Hard Thing About Software Development

#71

Post by tj-teej »

naasking wrote: post #52
ramzyo wrote: post #42

Earlier quoted context omitted.

> I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. Completely agree here. I often find myself wondering why 'Software Engineering' isn't the degree required to be a Software Engineer and further doesn't really exist as a major, whereas 'Mechanical Engineering', 'Electrical Engineering', 'Civil Engineering', 'Chemical Engineering', etc.…

> I often find myself wondering why 'Software Engineering' isn't the degree required to be a Software Engineer and further doesn't really exist as a major Because we don't yet understand software engineering. There has been insufficient empirical study of what yields maintainable/performant/what-have-you code, of what sorts of abstractions are "good" for maintenance/reuse/etc., at what's needed to reliably predict a…

+1 to this - not to say the cliche "AI is the future" statement, but careers span decades and if the fundamental dynamics of writing software changes mid-career you'll be glad you have a strong background in CS fundamentals rather than having taken "Java", "OO Programming", and "Scripting 101" classes.

Re: The Hard Thing About Software Development

#72

Post by [deleted] »

softawre wrote: post #58
Tutankamon wrote: post #57

The hardest thing about software development is having people in charge of you that know jack shit about software.

Funny, I've always thought the hardest thing about being an engineering manager is that by default all software engineers think they automatically know way more about everything than their management.

[deleted]

Re: The Hard Thing About Software Development

#73

Post by davidjnelson »

indogooner wrote: post #44

This is a post which touches on a subset of "hard" parts while downplaying other hard parts. I agree that a developer with a deep domain knowledge is precious. In fact, I have seen quite a few developers rising up the hierarchy despite being mediocre on technical skills. The code written by them is big ball of mud but they are good at communicating with stakeholders and understand the business well(And also good at d…

Great points.

> multiple if-elses encoding the business rules

A good architect would add a linter with a cyclomatic complexity check that fails the build. There's always a way to avoid these hideous nested else ifs. Code review is helpful here to train people who don't understand some of the various abstractions to avoid this such as polymorphism. This is also the code that has high value for unit tests.

Re: The Hard Thing About Software Development

#75

Post by xvaier »

cercatrova wrote: post #39
christophilus wrote: post #26

Earlier quoted context omitted.

Yes. The most successful projects I have worked on, we (the dev team, not project managers, not designers, etc) went on-site often. We observed our customers. We had lunch with them. We stood behind them as they worked. We asked them questions. We were on very friendly terms with them. We built systems that literally had people say, "Oh, thank God!" when demoed. I haven't seen any other development methodology that m…

The book Talking to Humans, shows this concept well, plus the book is free. http://www.talkingtohumans.com/index

Thank you for the suggestion, it was an excellent fast read, quite concise and insightful.

Re: The Hard Thing About Software Development

#76

Post by creeble »

s73ver wrote: post #25
johnny_reilly wrote: post #7

Earlier quoted context omitted.

Close. It's cache invalidation and naming things. But I feel ya

To make the joke work, I could only pick one. I thought naming things was the funnier option.

The joke is "There are only two hard problems in software: Naming things, counting, and naming things."

Re: The Hard Thing About Software Development

#77

Post by walrus1066 »

indogooner wrote: post #44

This is a post which touches on a subset of "hard" parts while downplaying other hard parts. I agree that a developer with a deep domain knowledge is precious. In fact, I have seen quite a few developers rising up the hierarchy despite being mediocre on technical skills. The code written by them is big ball of mud but they are good at communicating with stakeholders and understand the business well(And also good at d…

The way I see it, my job isn't to just blindly implement what the business thinks they want. It's a two way thing. If a set of business rules are too complex and convoluted, I explain that this incurs a cost, in increased likelihood of bugs, and slowdown of future development. We then think about how we can simplify the rules, or reduce complexity elsewhere. In one such case, we agreed with the business to remove an entire feature, to make the new feature more robust and easier to develop. I deleted 1/3 of a codebase as a result, ultimately the overall complexity of the system was substantially reduced after the new feature. It was immensely satisfying.

Re: The Hard Thing About Software Development

#78

Post by indogooner »

walrus1066 wrote: post #77
indogooner wrote: post #44

This is a post which touches on a subset of "hard" parts while downplaying other hard parts. I agree that a developer with a deep domain knowledge is precious. In fact, I have seen quite a few developers rising up the hierarchy despite being mediocre on technical skills. The code written by them is big ball of mud but they are good at communicating with stakeholders and understand the business well(And also good at d…

The way I see it, my job isn't to just blindly implement what the business thinks they want. It's a two way thing. If a set of business rules are too complex and convoluted, I explain that this incurs a cost, in increased likelihood of bugs, and slowdown of future development. We then think about how we can simplify the rules, or reduce complexity elsewhere. In one such case, we agreed with the business to remove an…

This is where a good product team helps. Understanding the threshold at which technical debt would undermine a business feature. Glad that it worked out well in your case

Re: The Hard Thing About Software Development

#79

Post by mfoy_ »

Terr_ wrote: post #33
mfoy_ wrote: post #28

Earlier quoted context omitted.

I'd love if that methodology were more common. The "traditional" method usually involves companies insisting we provide waterfall style proposals and they don't want to invest in up-front "mini-project" of having people analyze the problem _first_.

And heaven-forbid any developer actually calls up a customer or subject-matter expert without routing absolutely everything through one or more layers of middlemen and bureaucracy.

"Just send me your questions and I'll pass them along..." Because no one has _ever_ had a question answered and had a follow-up question based on the answer before... /s

Re: The Hard Thing About Software Development

#80

Post by Terr_ »

mfoy_ wrote: post #79
Terr_ wrote: post #33

Earlier quoted context omitted.

And heaven-forbid any developer actually calls up a customer or subject-matter expert without routing absolutely everything through one or more layers of middlemen and bureaucracy.

"Just send me your questions and I'll pass them along..." Because no one has _ever_ had a question answered and had a follow-up question based on the answer before... /s

True story: Myself and a bunch of internal customers are literally less than 50 meters away in the same office. The blessed middleman is in a different timezone 8 hours ahead.

So instead of a quick conversation 30 minutes with helpful whiteboard doodles, I have to compose my questions and decision-tree into an e-mail and wait at least for a day or two for a reply that may or may not be useful.

Post reply on HN