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

How to Build Good Software

csc.gov.sg

Post reply on HN
Print view View original

181–190 of 247 posts

Re: How to Build Good Software

#181

Post by mr_tristan »

cntlzw wrote: post #155
mr_tristan wrote: post #17

This struck a chord with me: "Software Is about Developing Knowledge More than Writing Code" I've experienced more issues caused by management passing around tasks between teams and never paying attention to knowledge and knowledge transfer. What's amazing, is that in over 18 years as a software engineer, I've seen this so many times. Teams will function well, then the institution tries to change. Often they will try…

+ 1 Yes, things really changed for me once I started to ask why we implement things. Tried to understand the manager/customer/stakeholder what is their domain? What kind of issue they want to solve? What is the business case we are working on? I know as a software developer you don't want to do that. More fun refactoring code than dealing with management. More fun writing that piece of SQL than sitting in a meeting.…

Good point: it's far, far better to be proactive, than wait for management to "recognize you".

Being a part of the early decision making processes has been a challenge for me as a remote employee. In larger companies, there are lots of meetings, discussions, and decisions that happen before anyone talks to the engineering staff is brought in. But, by basically being nice, asking questions, and really getting involved, I've been able to "weasel" my way into some of these discussions.

Once you get involved early on, there's so much more clarity around the one liner "requests" that often get farmed out.

Re: How to Build Good Software

#182

Post by wolco »

clumsysmurf wrote: post #42
mr_tristan wrote: post #17

This struck a chord with me: "Software Is about Developing Knowledge More than Writing Code" I've experienced more issues caused by management passing around tasks between teams and never paying attention to knowledge and knowledge transfer. What's amazing, is that in over 18 years as a software engineer, I've seen this so many times. Teams will function well, then the institution tries to change. Often they will try…

> "Software Is about Developing Knowledge More than Writing Code" The company I work for uses Scrum. They consider the User Stories + the code to be everything you need. I struggle with this, but my manager says they don't want to get tied up doing documentation "because it goes out of date". Beside, they are being Agile which "prefers working code over comprehensive documentation". I am wondering what other companie…

Change managers/leads

Re: How to Build Good Software

#183

Post by [deleted] »

mr_tristan wrote: post #17

This struck a chord with me: "Software Is about Developing Knowledge More than Writing Code" I've experienced more issues caused by management passing around tasks between teams and never paying attention to knowledge and knowledge transfer. What's amazing, is that in over 18 years as a software engineer, I've seen this so many times. Teams will function well, then the institution tries to change. Often they will try…

[deleted]

Re: How to Build Good Software

#184

Post by sailfast »

arethuza wrote: post #126
madeofpalk wrote: post #123

Earlier quoted context omitted.

> They consider the User Stories + the code to be everything you need If you have sufficiently detailed user stories, they can be.

When does a "sufficiently detailed user story" become "documentation"?

When it's only part of the ticket? Some teams call everything a "user story" when it might actually be it starts with the story format then adds a whole bunch of detailed acceptance criteria, the background for the story, etc.

Re: How to Build Good Software

#185

Post by matz1 »

whynotminot wrote: post #129
matz1 wrote: post #127

Earlier quoted context omitted.

They can learn them on their own time outside of work.

This is just an awful, awful mindset. If you want great devs, you're going to have to invest in junior devs, and you're going to have to expect them to be learning at work. This is also why the best use of your senior devs is as mentors to your less experienced ones.

Thats true if you have no choice.

But If you can hire great devs that already comes with the experience, required skill and you can pay for it, then why not?

If I'm a dev who is willing to put the time outside work to improve myself, wouldn't that put me in advantage when applying for job, compared to people who are not willing to put the time?

Re: How to Build Good Software

#186

Post by matz1 »

Aeolun wrote: post #143
matz1 wrote: post #127

Earlier quoted context omitted.

They can learn them on their own time outside of work.

This mindset is what leads to utterly incapable people being hired as seniors. If nobody is willing to hire junior or medior developers, then naturally everyone starts calling themselves senior.

How so ? If utterly incapable people being hired as seniors, isn't that failure in evaluating candidate ?

Senior/junior title designation shouldn't have much importance when evaluating candidate anyway, rather on what they can actually do or provide.

Re: How to Build Good Software

#187

Post by sailfast »

clumsysmurf wrote: post #42
mr_tristan wrote: post #17

This struck a chord with me: "Software Is about Developing Knowledge More than Writing Code" I've experienced more issues caused by management passing around tasks between teams and never paying attention to knowledge and knowledge transfer. What's amazing, is that in over 18 years as a software engineer, I've seen this so many times. Teams will function well, then the institution tries to change. Often they will try…

> "Software Is about Developing Knowledge More than Writing Code" The company I work for uses Scrum. They consider the User Stories + the code to be everything you need. I struggle with this, but my manager says they don't want to get tied up doing documentation "because it goes out of date". Beside, they are being Agile which "prefers working code over comprehensive documentation". I am wondering what other companie…

Traceability is where I'd start. First, ensure your stories are being linked to your code / pull requests / issues. That way you can figure out why something was changed in the future. This is key to determining whether you can change something down the road. Stories directly traceable to code can be powerful for capturing knowledge.

I might also recommend creating user stories for non-feature development like infrastructure and tech debt paydown (if you don't already). That way, all of the value flow is captured in one place and you're not just leading managers to see new features only.

Second, in addition to the user stories I'd advocate for strong background information about the context of the story as well as detailed acceptance criteria if you don't have that in place already.

Re: How to Build Good Software

#188

Post by base698 »

JohnBooty wrote: post #61
PaulRobinson wrote: post #50

Earlier quoted context omitted.

"prefers working code over comprehensive documentation" does not mean "don't do documentation". Documentation is essential. How things work is an important thing to document. Ideally it should be in version control and be generated from the code, because then it's less likely to go out of date. It still has problems (What do you do when the code and the documentation disagree? Which is correct?), but they're not as s…

Documentation is essential. How things work is an important thing to document. Ideally it should be in version control and be generated from the code, because then it's less likely to go out of date. My solution to this is old and fairly unpopular, but I stand by it: anything in the codebase that's not obvious to a new maintainer should have a brief, explanatory code comment. Generally, this falls into two categories…

Why not:

    return nil if country_code==KERPLAKISTAN and day_of_week==MONDAY
Then you don't need comments and the sync problem goes away?

Re: How to Build Good Software

#189

Post by [deleted] »

lelima wrote: post #119
siempreb wrote: post #102

> 3. Hire the best engineers you can. This is where most companies fail. Yes, they do want the best developers, but for the budget of an average junior/medior dev. For some reason most companies/managers I worked for do not understand the financial impact of a not so good developer. Or the other way around; they fail to value the best developers and are unable recognize them. I've worked for plenty companies where th…

>"3. Hire the best engineers you can." If every single company wants that, where is he space to grow and learn from mistakes? Maybe I'm wrong but I think those "mediocre dev's" learned a lot building a big app from scratch, solving bugs and refactoring.

[deleted]

Re: How to Build Good Software

#190

Post by ensiferum »

Silhouette wrote: post #173
ensiferum wrote: post #81

"2. Seek out problems and iterate;" This is bad advice. It's like saying "go into a bar and start picking up fights". If some part of the software has problems, runs slow or has bugs but nobody is complaining, then there's no problem. Why waste time improving it? Almost 100% of the time when you solve a problem you just create new problems of different kind in turn. Be lazy. The less code you write the better off you…

If some part of the software has problems, runs slow or has bugs but nobody is complaining, then there's no problem. This depends very much on context. To pick an extreme example, if you're writing the control software for a nuclear weapon and you know you have a bug that might cause it to activate unintentionally if you eat a banana while it's raining outside, I think we can reasonably agree that this is still a pro…

In your example youd hope some stakeholder to complain and raise an issue.
Post reply on HN