> the debate over labor and leisure is often fought between the Self-Helpers and the Socialists
I don't think those parties are they only ones who have something to say about leisure. Some would argue work is virtuous and you don't need less of it.
In the Netherlands, high schools are separated in three cohorts: practical education, higher education and academically oriented education. The latter are further divided in liberal arts tracks called 'Gymnasium' (notable for having Greek and Latin in the curriculum) and somewhat more practically oriented Atheneum. This has been the case since 1968.
You must switch depending on your results. The school does have a big say in it, and if you switch schools your parents could possibly make a case for you.
Lowest track - 4 years
Middle track - 5 years
Highest track - 6 years
I started and spent 3 years in the 'middle' track, in my third year I failed my French and German classes so badly that the school required me to either re-do the third year of the middle track, or go to the 4th year of the lower track. The funny thing is that the 4th year of the lower track does not have French or German as a requirement.
Since my parents did not really cared or bothered to stand up for me (unlike another girl, whose parents lobbied and she was allowed to go through to the next year with worse grades) I chose to do the lower track. Finished that up easily and was given the choice to go to the 4th year of the middle track (without French or German, the 3rd year was the final year with that requirement). Finished the middle track with ease as well.
Honest question, doesn't this creep people out? I mean, I'm obviously not the target market but I find it awkward enough when sites pop up those "Hi I'm <name>, how can I help you?" chat windows even though I know they're just a script. I can't imagine how I'd feel if I'd bought something a while back from a site and I got a personalized video from the person running it.
(Then again I did buy a Klein bottle a few years back and it came with basically a photo commentary of it being shipped and that was absolutely awesome, so...)
So, how exactly does this work? You get a notification that a customer has triggered your bonjoro, and then you record a video and send it to them via email?
I was just curious to know your number - it's an interesting data point. I have experimented with pricing, but not enough, so it's something I have to do at some point.
Not every product is maintained for years. In many cases it's good to be able to choose between a quick solution and a good solution, as long as these are concious decisions and some record of accrued technical debt is kept.
Rarely if ever in the beginning of the project it's 100% sure or guaranteed how long the project will be maintained. There might be some estimates, but in the long run upper management might change their minds at any time and then you are fucked if you didn't build robust architecture from the start.
At least according to my experience and everyone I know in the industry.
But there are so many counterexamples to that too. I worked on a project following CI practices with a release every two weeks, and I can think of plenty of examples where we developed a feature, tested it with users, and scrapped it within a month. That team leaned toward strict practices, and we wasted so much time on code review and documentation of small details which only existed for a couple of weeks.
I also thing it is vastly overstated how difficult it is to incrementally refactor a project which is "fucked". It's always possible to break it into smaller pieces, and gradually improve the codebase until it is manageable and easy to work with.
I also thing it is vastly overstated how difficult it is to incrementally refactor a project which is "fucked". It's always possible to break it into smaller pieces, and gradually improve the codebase until it is manageable and easy to work with.
What if there's no automated testing worth a damn, and the penalty for a bug is very high? Been there, done that, and I have to say, you don't ever want to stay there!
The point is there's a balance. I think it's perfectly reasonable to allow a certain amount of technical debt to accrue, especially when prototyping new features, and treat it as a priority to clear this debt by the time said features become a dependency to other parts of the project.
It takes a bit more nuance to get a team to work that way rather than just enforcing Best Practice(tm) always, but in my experience it can be much more productive overall.
I think it's perfectly reasonable to allow a certain amount of technical debt to accrue, especially when prototyping new features, and treat it as a priority to clear this debt by the time said features become a dependency to other parts of the project.
The point of code quality is to enable the company to change its mind or add new features. Over-perfectionism that gets in the way of this is going too far. At one company I worked for, the policy was not 100% strict DRY. Instead, we waited for 3 uses of the same idiom before we put it in the library. This prevented the collection of too many trivial methods, while still giving the benefits of DRY.
Often, the difference between a quick solution and a good solution isn't technical debt! (So long as there isn't an impediment to adding them in the future.) Missing features aren't technical debt.
Technical debt manifests in a code base, most generally as various forms of pain that occur when trying to add features. That's how the company "pays interest" on the technical debt. Coding so that you can always change your mind, however that is accomplished, is the key there. (This is one place where the "Law of Demeter" really shines!)
Sleeping helps against not sleeping enough. Who'd have thunk it.