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

Algorithms we develop software by

grantslatton.com

Post reply on HN
Print view View original

91–100 of 108 posts

Re: Algorithms we develop software by

#91

Post by euroderf »

lylejantzi3rd wrote: post #16
nkozyra wrote: post #7

Write everything (generally, new features) twice has turned out to be really good strategy for me, but it doesn't sit well with bizdev or project managers and tends to be perceived as unnecessary slowness. But if you plow through a feature and get it "working," you'll do much of that work cleaning up the logic and refactoring through your first pass. What rewriting allows you to do is crystalize the logic flow you de…

> it doesn't sit well with bizdev or project managers To be fair, it makes everything twice as expensive. Managers are always going to reflexively push back against that, even if the new feature covers that cost and more.

From the article:

> Rewriting the solution only took 25% the time as the initial implementation

Seems reasonable.

Re: Algorithms we develop software by

#92

Post by lylejantzi3rd »

euroderf wrote: post #91
lylejantzi3rd wrote: post #16

Earlier quoted context omitted.

> it doesn't sit well with bizdev or project managers To be fair, it makes everything twice as expensive. Managers are always going to reflexively push back against that, even if the new feature covers that cost and more.

From the article: > Rewriting the solution only took 25% the time as the initial implementation Seems reasonable.

> Seems reasonable.

Not to the manager, which is the point, not how long it takes to rewrite it.

Re: Algorithms we develop software by

#93

Post by simpaticoder »

Very interesting suggestions, all worth trying. Having a very capable coworker can help here, because they can show you what can be done in a short amount of time. Specifically I've noticed that some devs get "winded" by a change and want to take a break before moving on; others simply continue. This ability can be improved with practice, both within and across contexts. Doing things quickly is valuable for many intrinsic reasons that are often overlooked because we descry the poor extrinsic reasons. As with car repair, the odds that you forget how to reassemble the car scales with the time the repair takes. Similarly, if you can execute a feature in a day (especially a complex one that requires changes to many parts of a repo, and/or more than one repo) this is much less risky than taking many days or weeks. (To get there requires that you have firm command of your toolset in the same way a mechanic understands his tools, or a musician understands her instrument. It also requires that externalities be systematically smooth - I'm thinking particularly of a reliable, locally repeatable, fast CI/CD process.)

(The calculus here is a little different when you are doing something truly novel, as long periods of downtime are required for your brain to understand how the solution and the boundary conditions affect each other. But for creating variations of a known solution to known boundary conditions, speed is essential.)

Re: Algorithms we develop software by

#94

Post by probably_wrong »

from-nibly wrote: post #2

> "gun to your head, you have to finish in 24 hours, what do you do?" PSA: if you are a project manager / owner or some other similar position you do not get to ask this. This is a personal educational excercise not a way to get stuff done faster.

"Here, you have a gun to your head, you have to finish in 24 hours. What do you do?"

"I set aside the slides for the pointless CEO presentation tomorrow and work exclusively on this."

"No, you can't cancel on the CEO. Let's say you have two guns to your head and 24 hours, what do you do?"

"I take lots of coffee, skip sleeping tonight, cancel the group status meeting for Wednesday and focus on these two things."

"If you do that we'll look bad in front of the whole group. Let's say you have three guns to your head..."

Re: Algorithms we develop software by

#95

Post by DrScientist »

I find the follow approach quite useful.

1. First write down a bunch of idea of how I might tackle the problem - includes lists of stuff that I might need to find out.

2. Look at ways I break the task down to 'complete-able in a session'.

3. Implement, in a way the code is always 'working' at the end of session.

4. Always do a brain dump into a comment/readme at the end of the session - to make it easy to get going again.

Re: Algorithms we develop software by

#96

Post by kccqzy »

bdw5204 wrote: post #55
andsoitis wrote: post #13

Earlier quoted context omitted.

A project manager or bizdev person writes, rewrites, and rewrites again the document they produce do they not? Or do they write the perfect document at first go?

If I'm writing something, I'm writing it once. That "prewriting" stuff they teach in schools just slows down the process and makes you overthink your choice of words. I take the same "1 take" approach with code with the idea being to write the best solution on the first try. Why waste time writing something bad just so you can fix it later? That doesn't make any sense. As I'm writing, I do go back and make changes as…

Don't think of the first iteration as "prewriting" and instead think of the subsequent iteration as "editing."

Re: Algorithms we develop software by

#97

Post by snapcaster »

mgaunard wrote: post #29

Most software has a finite lifetime of a few years. You rewrite everything eventually. What you should be worried about is the code that hasn't been rewritten in ten years.

Weird, i would actually have the opposite conclusion. Can you say more?

>What you should be worried about is the code that hasn't been rewritten in ten years.

Why would I worry? it's been running for 10 years without significant changes. Isn't that a sign it's more or less accomplishing its purpose?

Re: Algorithms we develop software by

#98

Post by richk449 »

from-nibly wrote: post #2

> "gun to your head, you have to finish in 24 hours, what do you do?" PSA: if you are a project manager / owner or some other similar position you do not get to ask this. This is a personal educational excercise not a way to get stuff done faster.

Anyone have a reference to this technique? I’d like to learn more.

Re: Algorithms we develop software by

#99

Post by hintymad »

smusamashah wrote: post #63
hintymad wrote: post #48

I remember seeing somewhere a popular list of top 10 algorithms used in systems, and it's kinda depressing to realize that the most recent algorithm on the list, Skip List, was invented roughly 30 years ago, and every single one of them was taught in an introductory data structure course. That is, we most likely do not need to study the internals of algorithms nor need to implement them in production. For such a long…

Did you read the article?

You're right. I rushed and assumed. Thanks

Re: Algorithms we develop software by

#100

Post by kmoser »

ozim wrote: post #51
lylejantzi3rd wrote: post #16

Earlier quoted context omitted.

> it doesn't sit well with bizdev or project managers To be fair, it makes everything twice as expensive. Managers are always going to reflexively push back against that, even if the new feature covers that cost and more.

What hits hard is realizing that most features are not worth it. They just shouldn’t be developed. Unfortunately biznes wants features and more of them and if possible for free.

I find half my job as a developer is writing code, and the other half is advising clients on which features not to implement.
Post reply on HN