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

Software Engineering principles to make teams better

principles.dev

Post reply on HN
Print view View original

21–30 of 105 posts

Re: Software Engineering principles to make teams better

#21

Post by e40 »

hammock wrote: post #20
CraigJPerry wrote: post #6

I think i’ve got a slightly different take - i’m not saying my take is any better though. If we’re talking engineering principles, not team dynamics, then it’s: 1. Use immutability by default, even in languages that make that harder than it should be 2. Understand how liberating idempotency is 3. Divide and conquer, use abstraction to make hard problems manageable 4. Delete code, delete tests, re-write stuff, re-writ…

> 2. Understand how liberating idempotency is Can you give some examples?

And is another way to say this "side-effect free"?

Re: Software Engineering principles to make teams better

#22

Post by TeMPOraL »

chii wrote: post #19
mrits wrote: post #16

Earlier quoted context omitted.

Don't expect a better result after a rewrite. Be prepared to accept that.

> Don't expect a better result after a rewrite but what's the point then? why spend effort for it, if it isn't expected to be better?

> but what's the point then?

Learning. The result may not be meaningfully better, but you gain fuller understanding of the problem domain. The third rewrite might have a chance of being an improvement ;).

Re: Software Engineering principles to make teams better

#23

Post by [deleted] »

hammock wrote: post #20
CraigJPerry wrote: post #6

I think i’ve got a slightly different take - i’m not saying my take is any better though. If we’re talking engineering principles, not team dynamics, then it’s: 1. Use immutability by default, even in languages that make that harder than it should be 2. Understand how liberating idempotency is 3. Divide and conquer, use abstraction to make hard problems manageable 4. Delete code, delete tests, re-write stuff, re-writ…

> 2. Understand how liberating idempotency is Can you give some examples?

[deleted]

Re: Software Engineering principles to make teams better

#24

Post by rcfox »

e40 wrote: post #21
hammock wrote: post #20

Earlier quoted context omitted.

> 2. Understand how liberating idempotency is Can you give some examples?

And is another way to say this "side-effect free"?

The Linux shell command 'touch foo' is idempotent, but not side-effect free.

Reading a variable shared between threads without a lock is side-effect free but not idempotent.

Re: Software Engineering principles to make teams better

#27

Post by titzer »

Is it just me, but is this meme version of software engineering absolutely the lowest information density achievable? Seriously. This is a heavily-involved topic, where any project might require hundreds to thousands of hours of development, and we have five second soundbytes as principles. Ugh.

Re: Software Engineering principles to make teams better

#28

Post by lowercased »

TeMPOraL wrote: post #22
chii wrote: post #19

Earlier quoted context omitted.

> Don't expect a better result after a rewrite but what's the point then? why spend effort for it, if it isn't expected to be better?

> but what's the point then? Learning. The result may not be meaningfully better, but you gain fuller understanding of the problem domain. The third rewrite might have a chance of being an improvement ;).

You may just learned that there's no more meaningful improvement to be made. That should probably be documented somewhere after that discovery is made.

Somewhat relatedly, I've refactored processes down from 25 hours to 20 minutes. It got to 20 minutes, and other people started nitpicking that it could 'be faster' (the same people who'd let it get to 25 hours, then threw up their hands and said "it can't be fixed"). They spent loads of time getting it from 20 minutes down to... 17-18 minutes (spending 2+ weeks in the process). I'd indicated "there's really no more 'there' there - this is about as fast as it's going to get, without faster hardware". They had to find out for themselves there wasn't much more juice left in the tank.

Maybe it's not related, but I felt like sharing it anyway... :)

Re: Software Engineering principles to make teams better

#29

Post by cloverich »

chadlavi wrote: post #25

> Note: This visualization was designed for screens larger than 1024 x 1024 and for desktop-style interactions. You can proceed if you'd like. Why would you put in the work to warn people they'll have a bad time instead of just fixing the bad time.

Are you asking: "Why would you do less work when you could do more work?" -- not meaning to be trite I just think the answer follows directly from your question -- its much less work to say "I haven't optimized or even evaluated this for mobile" than to optimize a site for mobile, particularly if there is some important interaction you want which is easily achievable on a desktop sized screen (like drag and drop columns for instance).

Re: Software Engineering principles to make teams better

#30

Post by Scarbutt »

mrits wrote: post #16
CraigJPerry wrote: post #6

I think i’ve got a slightly different take - i’m not saying my take is any better though. If we’re talking engineering principles, not team dynamics, then it’s: 1. Use immutability by default, even in languages that make that harder than it should be 2. Understand how liberating idempotency is 3. Divide and conquer, use abstraction to make hard problems manageable 4. Delete code, delete tests, re-write stuff, re-writ…

Don't expect a better result after a rewrite. Be prepared to accept that.

You make it sound as they are talking about full rewrites but it's actually about rewriting stuff here and there.

You are also assuming one just rewrites stuff blindly and randomly without any prior new insight.

Post reply on HN