Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
AlmondSauce14637118dAll else being equal smaller ones. But I'd prefer a big, well organised & structured over a haphazard smaller one any day.
bagfox986118dI treat all projects equally bad.
rutee0719578118dBig ones, like 8 inches and above.
retoor112118dI prefer one weekend projects. My flaw is that i start over-enginering every time.
MVP should become my thing.
The only thing i like about micro services is that they are easier to complete. Besides that - fuck them too :)
willcandy631118dsorry, I think I like the Big ones, lasting little time.
Think about robbing a bank vs pickpocketing in the crowd.
Smaller is better, since you might get to finish it before you die !
I think my longest project I started in 1986..
That's how long ago..
Actually, I started one longer ago than that, in 1970 !
I might be finished in 6 months time. :-)
But then, I said that 6 months ago..
I remember management gave me a database project to do, they reckoned would keep me out of their hair for 3 months..
30 minutes later, I'd finished it. :-)
And I even got special permission to bring in my own keyboard !
Yes, security did check my paperwork. :-)
"Oi, why you leaving the building with one of our keyboards !"..
I remember a number crunching project I refactored so it only took 2 hours, instead of all day.
The rest of the day I was playing computer games when a surprise inspection happened.
I pointed out I'd done all the work assigned to me for that day, and I was even playing on my own computer !
I had to bring in my own computer, since the company didn't have their own...
No disaplinery action for me. :-)
Everyone else thought I'd be for the chop !
bittersweet43648117dBig projects, small pieces.
I've really gotten into developing code as (npm/composer/cargo/cabal/etc) packages.
Spend two days writing an API SDK for example. Write readme/docs, set up a simple CI, publish on package registry. In a private repo if it's specific to our business -- but I also write public & MIT licensed packages very often.
Let other coworkers glue it together, but still get the satisfaction of contributing on a larger project in the long term.