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

51–60 of 105 posts

Re: Software Engineering principles to make teams better

#51

Post by bobthepanda »

lowercased wrote: post #28
TeMPOraL wrote: post #22

Earlier quoted context omitted.

> 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").…

Meaningful improvement is in the eye of the beholder. There's the old tale of how Google found out 500ms in latency was a 1% drop in traffic. http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20....

20 to 17 minutes is a 15% time savings still.

Re: Software Engineering principles to make teams better

#52

Post by [deleted] »

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.

[deleted]

Re: Software Engineering principles to make teams better

#53

Post by rcfox »

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

In the sense that you're moving data in to a register and updating the program counter?

Re: Software Engineering principles to make teams better

#54

Post by RazorX »

Fishkins wrote: post #36
hammock wrote: post #20

Earlier quoted context omitted.

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

Say you have a batch job that performs tasks A–E, and each of those tasks might process thousands of records. At some point, something will go wrong that causes the process to crash, hang, or error over many records. If the code is not idempotent, you need to investigate exactly where things started going wrong and figure out how to resume the process at that point. You don't want to reprocess records and e.g. send o…

Last week I ordered a screen protector for my phone. I got two boxes in the mail. I thought I ordered twice by mistake but they had the same order number on the packing slip.

My immediate thought was that some order processing step somewhere is not idempotent.

Re: Software Engineering principles to make teams better

#55

Post by dkryptr »

AdamCraven wrote: post #33
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.

Can you show me where that is or what visualization that is? I haven't put anything on the website intentionally, perhaps it's auto generated. The only page that I haven't purposely optimised for mobile is the editor, as you can't really create principles on your mobile.

Their comment is on the wrong post. I think they meant to comment on this post: https://news.ycombinator.com/item?id=27689664

Re: Software Engineering principles to make teams better

#56

Post by AdamCraven »

oneshoe wrote: post #48

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 wond…

Oneshoe, thank you.

On the SDLC, it could work. The temporal aspect is something I need to think through in a way that's not too complicated. Getting feedback at this stage is beneficial, even if this hit HN a lot earlier than I was expecting.

Establishing your own principles is burdensome, but using others is not. Having access to everyone else's principles and being able to see what other successful teams use, makes it easy to take other people's capability and add it to your own. Imagine if you could see what principles Rob Pike or or the principles behind a library, framework or a particularly productive team? This gets me excited. It gives people the building blocks to make great things.

I totally agree that individual principles is extremely important. If not for the very fact that finding and being on aligned teams is an amazing experience for everyone involved. Happier, more productive teams.

I would love to have an informal chat with you, you get what I'm doing and it needs people like you to for this to succeed for the community. Drop me an email if you can take me up on the offer :)

Re: Software Engineering principles to make teams better

#57

Post by AdamCraven »

akhilpotla wrote: post #50

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.

I imagine teams will shared their principle lists on blog posts and put reflections there.

Not all of it would appear on the principles.dev, as I think the reflective nature would be best handled elsewhere. But acknowledging pros and cons on the website is very valuable.

The next big piece of work I have to do is on principle lists ( https://github.com/PrinciplesDotDev/principles/discussions/2...) and figuring out what features to include and where to draw the line is going to be tricky... I need to find the principles behind it, really.

It's interesting that you say they would be a valuable resource for a junior and mid-career engineers. I agree, it would. What I've found is it generally attracts people who are a) leaders (in some form or other) b) care about programming deeply.

Re: Software Engineering principles to make teams better

#58

Post by majkinetor »

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…

Everything is great there, and in particular number 2 is awesome and 5 is FTW !

Also, don't let people guess what are those commands - create a menu that is run as soon as you clone the repo and shows all commands. I now use Invoke-Build [1] system for that and on all projects you type ib ? to get that list and later ib to execute it (or any combination of it, i.e. ib DropDatabase, Run, Test). Basic tasks are named the same on all projects no matter the underlying technology.

Later you use the same command on CI server - its just another developer that runs ib Build, Test, Publish. Any more programming in CI yaml files then 1 to 3 lines per job is so wrong.

[1] https://github.com/nightroman/Invoke-Build

Re: Software Engineering principles to make teams better

#59

Post by tgb »

Fishkins wrote: post #36
hammock wrote: post #20

Earlier quoted context omitted.

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

Say you have a batch job that performs tasks A–E, and each of those tasks might process thousands of records. At some point, something will go wrong that causes the process to crash, hang, or error over many records. If the code is not idempotent, you need to investigate exactly where things started going wrong and figure out how to resume the process at that point. You don't want to reprocess records and e.g. send o…

How do you make something idempotent if one of the effects is sending an email?
Post reply on HN