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

81–90 of 105 posts

Re: The Hard Thing About Software Development

#81

Post by ikeyany »

oldrny wrote: post #35
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…

It seems like your suggestion is a little backwards -- computer science is its own thing, and for some reason, people started thinking that computer scientists are ideal software developers. Since that clearly isn't the case, employers should look for some other certification that's more in line with what they require from an employee.

> for some reason, people started thinking that computer scientists are ideal software developers

Musicians generally are. But all the talented ones are drawn to more fun, lower paying careers.

Re: The Hard Thing About Software Development

#82

Post by mfoy_ »

Terr_ wrote: post #80
mfoy_ wrote: post #79

Earlier quoted context omitted.

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

Are there repercussions to just walking over and asking them then forwarding the middleman a summary / recap?

Re: The Hard Thing About Software Development

#83

Post by learc83 »

ramzyo wrote: post #46
tnecniv wrote: post #45

Earlier quoted context omitted.

> Not a CS major myself, but amongst my friends who did their undergrad in the US I don't think they had any classes that covered requirements gathering, putting together schedules, etc. Any CS majors here have a class/classes that covered those topics? We did this as part of our open ended senior project.

Interesting, maybe a more informative question for me would be - if you did have a class/classes that covered those topics, did you feel that they prepared you sufficiently for a job as a software engineer? But now I'm starting to sound like an alumni survey... :)

My degree required a class like this. It was the most useless class I took.

The theory heavy classes (automata, algorithms etc...) covered material that changes very slowly.

But, as a previous poster said "we don't yet understand software engineering." Because of this software engineering best practices change with the wind. As a result, the software engineering class was a hopelessly outdated survey of how software was built in the early 90s when our professor last worked in industry.

Re: The Hard Thing About Software Development

#84

Post by learc83 »

lomnakkus wrote: post #54
sidlls wrote: post #50

Earlier quoted context omitted.

"Software Engineering" does exist as a degree. Or it used to (15 years ago).

Indeed, it does exist, but IME SE education is just "CS light". I'm not saying that to be disparaging for the sake of it[4], but: there's nothing close to traditional engineering in the software development world[2]. It's basically just business interests coopting the term to try to seem more legit -- and of course they established the equivalent of trade schools for CS as SE. For those in the know SE education is a…

Software is less like mechanical engineering and more like industrial engineering or systems engineering.

Designing an assembly line to build a car vs designing a car.

The difference even with those disciplines is that with code, any specification sufficiently detailed to replicate the product is the product.

An architect can design a blueprint for a house and send it to 3 different builders and they will each build more or less the exact same house.

But if you write a software spec and send it to 3 different software teams, you will get 3 very different products. If you try to write a sufficiently detailed spec to avoid this problem, you'll just end up writing code.

Re: The Hard Thing About Software Development

#85

Post by learc83 »

ebola1717 wrote: post #15
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…

Yup, Sarah Mei had some good thoughts on this, in the context of bootcamp grads vs CS grads: https://twitter.com/sarahmei/status/862569071631491072

She basically just throws out bootcamp grads have better soft skills with nothing to back that up.

If that's true, and I've never seen any actual evidence to believe that it is, my guess is that it's because bootcamp grads are older the CS grads in general.

They're usually career switchers and they have experience from that previous career. You really shouldn't be comparing a 35 year old ex-teacher, or a 28 year old law school grad to a 22 year old CS grad on the soft skills front.

Re: The Hard Thing About Software Development

#86

Post by cromd »

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 not having enough breadth in "one skull" is largely created by psychology and structure at companies and less by curriculum deficiencies. When I used to manage developers, most of them told me that they were pained by how little they were expected to interface with non-developers. These were very technical people, but they still wanted variety and connection/relevance to the product.

Even developers with good interpersonal skills or business sense are discouraged from participating in more producty discussion. They may be encouraged by way of somebody taking them aside early in their career and saying "Hey kid, you really _get it_. You're not like the rest of these nerds. How about you start calling shots on what to build and switch to a product role?" But they'll rarely be encouraged to stay as technical while simply getting listened to more by management. Management may argue that after 2 or 3 years of getting one's hands dirty, you understand programming as well as you need to, and that for the rest of your career, persuasion trumps skill acquisition. It's somewhat taboo to cultivate both skill sets at the same time. So, I think even if you got more "people people" to study CS/whatever, a reverence for specialization will silence a lot of voices.

Re: The Hard Thing About Software Development

#87

Post by LrnByTeach »

phkahler wrote: post #31

Favorite line "... the software development process is exploratory by nature." I always say the customer/client does not have requirements, they have problems. You will not discover all the requirements until you start solving some of the problems and providing solutions. Only then will they say "oh but...." and drop more requirements on you that they didn't think of up front. Back to that quote. It's not that softwa…

Great points from OP and above comments ..

> the software development process is exploratory by nature

>> customer/client does not have requirements, they have PROBLEMS. You will NOT DISCOVER all the requirements until you start SOLVING SOME of the problems and providing solutions.

> "The most valuable asset in the software industry is the synthesis of programming skill and deep context in the business problem domain, in one skull."

> But If Someone Else Knows the Business, Why Can't They Can’t They Just Give Me a Spec?

> The Unmapped Road

>Miles and miles of a software project are spent roving this vast territory that is not exactly computer related, nor exactly business related. Rather, it is a new and emergent problem space that explodes into existence while bridging the middle distance between the business problem and the technology.

> In reality, this vast field of micro-problems was there all along. But the only way to discover them was to encounter them one at a time, like boulders in the path of a road-laying crew

> What is Deep Context?

> Deep context is the state of having achieved a kind of mental fluency in some large percentage of this immense field of micro-problems that appears in the space between technology and a business domain.

Re: The Hard Thing About Software Development

#88

Post by Terr_ »

mfoy_ wrote: post #82
Terr_ wrote: post #80

Earlier quoted context omitted.

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.

Are there repercussions to just walking over and asking them then forwarding the middleman a summary / recap?

There was a "Hey, don't do that, X needs to be in the loop" complaint. (Didn't see it myself, but technical program manager who was also in on the meetings told me.)

Later that remote person left the company, and the position was left unfilled for a year and some projects got mothballed.

Re: The Hard Thing About Software Development

#89

Post by markbnj »

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.

It does create the framing but I just don't see how it is relevant to the conclusions drawn. There are entire companies that are remote and are obviously able to communicate problem domain expertise and execute effectively.

Re: The Hard Thing About Software Development

#90

Post by lomnakkus »

learc83 wrote: post #84
lomnakkus wrote: post #54

Earlier quoted context omitted.

Indeed, it does exist, but IME SE education is just "CS light". I'm not saying that to be disparaging for the sake of it[4], but: there's nothing close to traditional engineering in the software development world[2]. It's basically just business interests coopting the term to try to seem more legit -- and of course they established the equivalent of trade schools for CS as SE. For those in the know SE education is a…

Software is less like mechanical engineering and more like industrial engineering or systems engineering. Designing an assembly line to build a car vs designing a car. The difference even with those disciplines is that with code, any specification sufficiently detailed to replicate the product is the product. An architect can design a blueprint for a house and send it to 3 different builders and they will each build…

This is not exactly a "response", but as you point out, I failed to point this out in my comment: There is little actual value in (what are you doing here? go outside).

Obviously, I'll elaborate if necessary, but really... do you actually need other people to tell you how to live? (Ding, another achievement realized. No, not really, I just thought it would be funny.)

EDIT: For a more comprehensive treatment see the film "Scott Pilgrim ..."

Post reply on HN