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

41–50 of 105 posts

Re: Software Engineering principles to make teams better

#41

Post by EricE »

titzer wrote: post #27

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.

If you have ever heard any sports announcer/commentator go on and on about "the fundamentals" - well, here you go. As he points out little things quickly add up into big things. Don't take my word for it - search out just about any interview with a successful athlete about their career and I guarantee at least some, if not a significant chunk of it will dwell on the topic of "fundamentals".

Re: Software Engineering principles to make teams better

#42

Post by macintux »

wlpu wrote: post #32
macintux wrote: post #18

Earlier quoted context omitted.

> Use immutability by default, even in languages that make that harder than it should be That and referential transparency are huge wins. It is a shame languages like Python make it such a challenge.

It's easy to do immutability in python, just use NamedTuple for classes and tuple instead of list

I’ll research those, thanks. Any suggestions for OSS projects that do so today?

Re: Software Engineering principles to make teams better

#43

Post by japanuspus »

wlpu wrote: post #32
macintux wrote: post #18

Earlier quoted context omitted.

> Use immutability by default, even in languages that make that harder than it should be That and referential transparency are huge wins. It is a shame languages like Python make it such a challenge.

It's easy to do immutability in python, just use NamedTuple for classes and tuple instead of list

...or `dataclass(frozen=True)` if you need the ergonomics.

For non-primitive members, `frozenset` is in the standard library, but frozen dictionaries are unfortunately lacking.

Re: Software Engineering principles to make teams better

#44

Post by joshuamorton »

wlpu wrote: post #32
macintux wrote: post #18

Earlier quoted context omitted.

> Use immutability by default, even in languages that make that harder than it should be That and referential transparency are huge wins. It is a shame languages like Python make it such a challenge.

It's easy to do immutability in python, just use NamedTuple for classes and tuple instead of list

Please don't do this, there are far better approaches. Use dataclasses/attrs that are frozen for immutable record types.

(Specifically avoid namedtuples unless you're hoisting a tuple to a real record. Record types also being a weird union with a tuple is...oft confusing)

For immutable basic data types, adopt type annotations and prefer to use sequence/iterable and mapping to direct didn't/list types. These provide statically verifiable immutability and also allow begin to encourage useful async-friendly patterns.

Re: Software Engineering principles to make teams better

#45

Post by zomglings »

rcfox wrote: post #24
e40 wrote: post #21

Earlier quoted context omitted.

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.

Interestingly, `touch` is not idempotent because it modifies timestamps. Not being pedantic, just an interesting consideration. `mkdir -p` is idempotent, I believe.

Re: Software Engineering principles to make teams better

#46

Post by zomglings »

omegalulw wrote: post #38
rcfox wrote: post #24

Earlier quoted context omitted.

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.

Reading a variable isn't side-effect free either :P

Opening Schrodinger's box isn't side-effect free. :)

Re: Software Engineering principles to make teams better

#47

Post by mytailorisrich »

zomglings wrote: post #45
rcfox wrote: post #24

Earlier quoted context omitted.

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.

Interestingly, `touch` is not idempotent because it modifies timestamps. Not being pedantic, just an interesting consideration. `mkdir -p` is idempotent, I believe.

You're absolutely correct, it's not idempotent for the crucial reason you mention. It's crucial because updating the timestamps is the main purpose of 'touch' in the first place!

Re: Software Engineering principles to make teams better

#48

Post by oneshoe »

I'm pretty excited about this site's potential. I am avid promoter of creating autonomous teams through principles and goals alignment (OKR).

I think there were suggestions about Time being an aspect of a principle. I wonder if this would be better represented by the SDLC stages, something like this might address the "time" part that allows it to be associated with type of work being done. Just a thought. I also wonder, at the same time, if this is too burdensome for a team or individual to do. Establishing your principles, IMHO, should be the most important thing you do, if you use them to guide your behavior.

I also have hope that when people establish what their individual principles (that define them) they then can ensure when they are job hunting or self reflecting on their current job that they what they are doing is aligned with who they are to ensure they will be satisfied in that role/job/company.

I just bookmarked the site. Excited to see this grow.

Re: Software Engineering principles to make teams better

#50

Post by akhilpotla »

I think it would be interesting to read case studies of different teams, their principles, how those decisions have impacted them, benefits, drawbacks from their approach, etc.

I think principles are great, but like you yourself have said, they require context. I would especially be a valuable resource for junior and mid career engineers, of which I am one.

Post reply on HN