The hardest thing about software development is having people in charge of you that know jack shit about software.
Vica versa, many developers don't know jack about the business they work for, and make little or no effort to.
The Hard Thing About Software Development
61–70 of 105 posts
Re: The Hard Thing About Software Development
#62The hardest thing about software development is having people in charge of you that know jack shit about software.
Man does that ring true on this Friday morning.
I'm working with an intern who's implementing a "proof-of-concept" for voice control using both Alexa and API.AI (Google). He's a CS freshman. It's amazing what he's gotten working so far, but his code is unreadable noise. Like he never learned what a subroutine is for.
But he's giving a demo to the CEO today, and said CEO will undoubtedly say "Nice, finish it and let's ship!" when it's probably not even usable code in any way. The hard part -- connecting thousands of users through a db and thousands of persistent cloud connections from individual IoT devices, hasn't even been sketched yet.
So he looks like the hero (with a demo that does something amazing), and I'm going to look like the can't-get-it-done idiot because no one in the organization understands the complexity of going from that proof-of-concept to a working product, or even a next-level demo that uses actual connections from actual devices.
Of course, that's when you're supposed to quit, I guess.
Re: The Hard Thing About Software Development
#63The 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.
Which is very wrong: You get domain knowledge by mapping out the field (as stated in TFA), which can happen regardless of where you physically sit.
Case in point: I've been working remotely for 2 years now, and I've gathered as much domain knowledge (if not more) as I had in previous roles over the same timespan.
What's important is to get your software out there, so you can map the field.
Re: The Hard Thing About Software Development
#64> The nature of the beast is that software requirements rarely change Put like this, it's hard to agree with the above statement. Following the spirit of the article, I assume the author means that the problem domain is pretty stable. But I've been in this for more than 20 years, and I know that requirements always change. Not only our understanding, but also the customer/user's understanding of their needs and prior…
> Not only our understanding, but also the customer/user's understanding of their needs and priorities change. And not only does understanding change, but the business requirements actually change too depending on market conditions.
I think the notion of "requirements" the author refers to is what the business actually does. When writing say health-care management software for say, a hospital chain, they're not going to suddenly decide, no matter how much the small-r requirements change, that they instead want their software to be able to do capacity management for lumber mills.
The business domain constrains the field over which the requirements can change, and the sort of deep context which the author mentions will also range over that field.
Re: The Hard Thing About Software Development
#65Yeah programmers / developers / software engineers act as an interface for other people for computers. It's not surprising that these qualities of that 'interface' affects price: - intuitiveness i.e how easy is it to communicate with this person (language fluency, etc...) - quality i.e. how well do this person understand not only the requirements but also the actual goals - 'latency' i.e. how convenient and how fast…
This is insightful. These are possible remotely though:
* intuitiveness i.e how easy is it to communicate with this person (language fluency, etc...)
Native English speakers have an advantage here.
* quality i.e. how well do this person understand not only the requirements but also the actual goals
Experience, empathy, critical thinking, intelligence. Not necessarily common or easy but on site vs remote doesn't affect this really.
* 'latency' i.e. how convenient and how fast can you communicate with this person (time zone,
Hire people from your country or even your time zone.
* can you both see facial expressions, hear changes in voice, etc...)
Use video chat constantly.
Remote work is a skill like any other. It makes sense most employers that offer it require 5+ years doing it previously. The article author makes a good point. A great way to get this is to work at a company with many remote employees and start on site before transitioning to full time remote.
Maybe some people are just cut out for remote too. I remember at the beginning of my career running a business where I talked to the CEO of a mid sized company regularly about his needs, and always delivered. He was thrilled and amazed. It was just good listening, communication, programming skill and hard, applied work. Nothing fancy.
The weird thing about the Bay Area is if you want to live on 5 acres in a home built in the last five years somewhere quiet and pretty that is 20 minutes from the office in traffic, you're basically looking at Woodside. On the low end, those houses start at around 3 million. Good luck paying that mortgage on the income of even two software engineers.
Whereas you could buy the same house somewhere else in California for 300k.
So even though it is indeed pleasant to have coworkers to talk to in person for social needs, the compensation to housing cost math just flat out doesn't come close to working unless you are willing to make some serious housing quality sacrifices.
Edit: typo.
Re: The Hard Thing About Software Development
#66The 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
#67The 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.
To a large margin I agree. If an engineer (or anyone really) can't clearly concisely explain their position and reasoning, they likely don't understand the problem as well as they believe they do.
Re: The Hard Thing About Software Development
#68Earlier quoted context omitted.
> It makes me think that we're training the wrong people in college by making CS a very difficult, math heavy field which often causes the more human skilled people to drop out. I disagree. I think instead there is a category error being made: that CS is an appropriate degree (on its own) to become a software engineer. It's like suggesting a BS in Physics qualifies somebody to work as an engineer building a satellite…
> 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 took a class titled "Software Engineering" (or maybe "Software Development") that covered these things. I believe it was one of several upper-level electives I could have chosen, though, so I could have avoided taking it and still gotten my CS degree.
Re: The Hard Thing About Software Development
#69Earlier quoted context omitted.
> Not only our understanding, but also the customer/user's understanding of their needs and priorities change. And not only does understanding change, but the business requirements actually change too depending on market conditions.
I think the notion of "requirements" the author refers to is what the business actually does. When writing say health-care management software for say, a hospital chain, they're not going to suddenly decide, no matter how much the small-r requirements change, that they instead want their software to be able to do capacity management for lumber mills. The business domain constrains the field over which the requirement…
> When writing say health-care management software for say, a hospital chain, they're not going to suddenly decide, no matter how much the small-r requirements change, that they instead want their software to be able to do capacity management for lumber mills.
But they might start with wanting billing software, and then change their minds and ask for software to do triage and scheduling operating rooms. That's almost as drastic a change in scope as your big-r from health to lumber mills, so I don't really agree with the distinction you're trying to make.
Re: The Hard Thing About Software Development
#70The 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.
Maybe they just know way more about software development than the engineering manager if said engineering manager has never done actual software development.
Of course both viewpoints are valid, I'm just really feeling the commenter's point today because of my particular circumstance.