zlacker

I don't like this definition of Software Engineering that necessitates a team of Other People. Perhaps I'm outright wrong that such a definition just shouldn't be. Even in that case, I just don't like it. :)

>>jagged+(OP)
If you broaden the definition of Other People to "you, 6 months from now" and "you, 6 months ago", then many SE principles still apply. Where SE principles don't apply is toy, one off scripts that you just hack together to get a single thing done and require no maintenance like a lot of stuff in science.

>>shalma+Qo
Absolutely true. Not even 6 months needed.

When I do stuff for myself I apply the same principles I apply at work. It's insane how easy it is to change stuff later on. Didn't think about this use case before but now you do? Because I have properly maintainable code that is readable its very easy to change and changes are only needed in one place instead of all over the place. Knowledge of the right thing is kept in the right place instead of implicit knowledge all over the code etc.

It also helps to have 'one team be responsible for each service' instead of 'everyone can work on everything'. It's insane how fast you can move if you know the code well and it's maintainable.

>>shalma+Qo
I'm the poor schlub that usually needs to maintain the code that I write.

I also pretty much never get questions about the code that I pass on to others.

I write about my process here: https://littlegreenviper.com/miscellany/leaving-a-legacy/

(Long screed. Few read it).

>>shalma+Qo
Strangely enough, software engineering is mostly about humans rather than about software. Take any side project of yours (no matter if it has been hacked together or if the best practices out there have been applied): add pressure to make money out of it, pressure to deliver it at a given date and a bunch of individuals you must collaborate with to push the project live, and right there you get SE.