The Hard Thing About Software Development • Hacker News Board

Re: The Hard Thing About Software Development

#21

Post by MrPatan » Fri, Jul 14, 2017, 4:03 PM UTC

FLUX-YOU wrote: post #14

Here's the problem: - Here's a pool of knowledge about software development: hardware, operating systems, memory, disks, file formats, databases, networks, protocols, languages, debuggers, design patterns, security, accessibility, UI/UX, distributed systems, paradigms, typical algorithms & data structures, and CS problems - There's a pool of knowledge about whatever industry you get into as a developer: user demands,…

There is hope.

How about instead of becoming the expert at whichever business domain the software is for, we become experts at helping business domain experts find and express the business rules that need to be implemented?

You can fit a decent amount of that skill and the technical knowledge you mentioned in one skull, and it still lets you be quite effective in more than one domain.

That's what I'm going for anyway. Wish me luck.

Re: The Hard Thing About Software Development

#22

Post by scierama » Fri, Jul 14, 2017, 4:04 PM UTC

mfoy_ wrote: post #20

markbnj wrote: post #19

The author could have just left the "Remote" part out. This piece is really about hiring independents for gigs vs. building and educating your own team.

I thought something quite similar, but upon further reflection the "remote" buildup and conclusion sets the narrative frame for the rest of the article. Rather than just a "wisdom dump" it becomes more of a story with a purpose.

Yes, the entire article is an attack on remote working and this suits Amazon well since they keep trying to get people to relocate to Seattle.

Re: The Hard Thing About Software Development

#23

Post by RegW » Fri, Jul 14, 2017, 4:04 PM UTC

markbnj wrote: post #19

The author could have just left the "Remote" part out. This piece is really about hiring independents for gigs vs. building and educating your own team.

I read it as: remote devs don't gain the domain knowledge.

Re: The Hard Thing About Software Development

#24

Post by lordCarbonFiber » Fri, Jul 14, 2017, 4:07 PM UTC

haburka wrote: post #2

I agree completely. Rarely the hard problems in coding are thinking of a clever algorithm, or solving a particularly nasty scaling problem. Usually I've struggled the most with understanding and building what the customer needs. A spec can be interpreted many different ways and will always have to be polished after its completed. Someone who doesn't know what the customer expects will almost certainly create an imple…

The issue there is CS != programming. The conflation of the 2 has created an artificial demand for CS trained people (to jump through the stupid interview tests) but the vast majority of jobs need almost no academic knowledge. We're an industry starving for mechanics bitching about the fact that Mechanical Engineers want to build better engines.

Re: The Hard Thing About Software Development

#25

Post by s73ver » Fri, Jul 14, 2017, 4:08 PM UTC

johnny_reilly wrote: post #7

s73ver wrote: post #4

I thought the hard thing in software development was naming things and off by one errors?

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.

Re: The Hard Thing About Software Development

#26

Post by christophilus » Fri, Jul 14, 2017, 4:13 PM UTC

xvaier wrote: post #6

As a lead developer building a platform dealing with the intricacies of union agreements and labor restrictions, this summarizes exactly the thought process that my team has gone through in the last year. We started with a simple problem that plagues HR departments in every conceivable industry with unions, finding substitute personnel and erroneously assumed that it was a simple fix. Over the past year and a half we…

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 matches it. You really have to understand a problem at a deep level in order to reason well about it.

Re: The Hard Thing About Software Development

#27

Post by mfoy_ » Fri, Jul 14, 2017, 4:13 PM UTC

arethuza wrote: post #5

haburka wrote: post #2

I agree completely. Rarely the hard problems in coding are thinking of a clever algorithm, or solving a particularly nasty scaling problem. Usually I've struggled the most with understanding and building what the customer needs. A spec can be interpreted many different ways and will always have to be polished after its completed. Someone who doesn't know what the customer expects will almost certainly create an imple…

I think that's an argument for fewer people doing math-oriented CS courses as "training" for being a developer rather than changing the nature of CS courses.

Agreed, I think "Computer Science" is being incorrectly marketed as the program for aspiring software developers. It does not focus on the skills and knowledge needed to actually do the job, with the exception of some rather niche problems.

Re: The Hard Thing About Software Development

#28

Post by mfoy_ » Fri, Jul 14, 2017, 4:18 PM UTC

christophilus wrote: post #26

xvaier wrote: post #6

As a lead developer building a platform dealing with the intricacies of union agreements and labor restrictions, this summarizes exactly the thought process that my team has gone through in the last year. We started with a simple problem that plagues HR departments in every conceivable industry with unions, finding substitute personnel and erroneously assumed that it was a simple fix. Over the past year and a half we…

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…

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

Re: The Hard Thing About Software Development

#29

Post by ramshanker » Fri, Jul 14, 2017, 4:19 PM UTC

jeddf wrote: post #16

Joe-Z wrote: post #11

Earlier quoted context omitted.

This article also struck a chord with me. About 3 years ago I started working half-time as a software developer at a civil engineering company. Originally they wanted to hire me because they had some 3D visualizations in their software with which they had problems and I, coming from a game development background, could help them out. By now, I'm deeply immersed in geotechnical topics on a daily basis and I think it's…

Lovely to hear you have a position at the intersection of software and civils like this. I am a software dev that switched careers shortly after graduating with a civil & structural degree, always thought I'd be of most value combining the two at some point. There is hope!

Another Civil & structural guy here. The ability to code does magic at times. Many design steps can be automated. It need not be something huge. Once I automated transfer of data from one software to anther using EXCEL VBA which used to take 2+ Man-days in manual style. Within a month almost entire department was using this excel sheet to do this particular task. Fun times.

Re: The Hard Thing About Software Development

#30

Post by mfoy_ » Fri, Jul 14, 2017, 4:19 PM UTC

scierama wrote: post #22

mfoy_ wrote: post #20

Earlier quoted context omitted.

I thought something quite similar, but upon further reflection the "remote" buildup and conclusion sets the narrative frame for the rest of the article. Rather than just a "wisdom dump" it becomes more of a story with a purpose.

Yes, the entire article is an attack on remote working and this suits Amazon well since they keep trying to get people to relocate to Seattle.

It is not an attack on remote working. It is an attack on the naive assumption that there is worthwhile value in being handed a stack of detailed requirements and implementing them with no back-and-forth.