To explain for those not in Canada… It is usual in Canada for a job to start with a low level of PTO an then add a week every few years that you stay with the company. This usually is capped at 6 weeks.

You can, of course negotiate an amount of PTO when you accept a job. Someone coming into a more senior position wouldn’t expect to start with just two weeks of PTO.

20.5 in winter and 21.5 in the summer.

I call BS.

I’m Canadian and my parents immigrated here from England before I was born. I have a UK passport as well as a Canadian passport.

I’m not English-Canadian, I’m just Canadian. No one hyphenates in Canada, and you cannot say that Canada has any more unifying cultural heritage than the USA.

In the very first real programmer job that had, back in 1986, the IT department estimated that they had a 51 man-year backlog of development work. That would have translated to two or three calendar years of work. Probably more, considering how crappy estimates always are, and the always under-estimate.

It turns out that this is pretty much the industry standard. Virtually ever place I worked for the next 35 years had a similar size of backlog. And that backlog isn’t standing still, either. All you can hope is that 3 more years worth of new requests don’t come in during the two years it takes to complete what you already have.

Some of those new things are going to have a higher priority than stuff that’s already in the backlog. The reality is that some item that’s down at the low end of the list is going to get bumped down, again and again, and never get done. Or it’s going to someday become an urgent priority that can’t wait any more.

So the pressure is always intense for the developers to go faster, faster, faster. And the business doesn’t understand or care about good engineering practices, even though the shit hits the fan when a critical bug gets released to production. And God help you if that backlog of 51 man-years has grown to 70 after a year because of the technical debt you introduced trying to go faster.

The fight to rein in scope is constant. At that first job, the head of the department told us, “to build Volkswagens, not Cadillacs”. It was laughable, because they were struggling to keep up while building Skodas.

You can’t just add more programmers because the productive backbone of the development team is a group of programmers that have all been there for at least 5 years and they are domain experts. It’s going take at least 5 years to bring new hires up to that level of knowledge.

And that’s all three sides of the project triangle: scope/quality, resources and time. You can’t meaningfully add resources, scope’s already stripped down to bare bones and the time is too long.

And the truth is that every one of those projects in that 51 man-years backlog is important, even critical, to some aspect of the business. But the development process is unfathomable to muggles, so can’t you just go faster? Can’t you wring a bit more productivity out of those domain experts?

“My nipples explode with orgasmic delight”.

Except I’m not actually talking about spelling, per se, but about attention to detail. Spelling errors in a resume is just sloppy rubbish.

As an IT/Development manager, I only had one role that I hired for where the skills for getting the job matched the skills for doing the job: Business Analyst. Not job entailed presenting information clearly, both written and verbally. So I expected the resume and cover letter to be organized and clear.

Programmers, on the other hand, I wouldn’t expect the same level of polish. But I would expect a complete absence of spelling errors and typos. Because in programming these things count – a lot.

A lot of the people that applied, and that I hired, did not have English as a first language. So I gave a lot of latitude with regard to word selection and grammar. But not spelling. Use a goofy word or two, but spell them right.

I figured that most people were highly motivated when writing a resume – about an motivated on you can get. And if not level of motivation cannot get you to take care, then you’ll just be a bug creation machine if I let you touch my codebase.

Proper pickled onions and Branston pickle.

Bob’s Red Mill makes an adequate substitute. It’s not as uniform as McCann, but it is good.

It seems more rikely, if hit by an IBM truck in 1985 that he would be ebcdic’d to Seattle.

FWIW: It never even occured to me that they might have meant removing speed limits. I had to go back and re-read it a few times to see what the beef was.

Context is important here. Sure, “drop” could mean two things, but anything other than “lowering” in this case wouldn’t make sense. IMHO, at least.

No way. When something numerical is “dropped” it usually means lowered. Especially in the form “drop numerical value”, as was this case.

This is true, but…

Moore’s Law can be thought of as an observation about the exponential growth of technology power per $ over time. So yeah, not Moore’s Law, but something like it that ordinary people can see evolving right in front of their eyes.

So a $40 Raspberry Pi today runs benchmarks 4.76 times faster than a multimillion dollar Cray supercomputer from 1978. Is that Moore’s Law? No, but the bang/$ curve probably looks similar to it over those 30 years.

You can see a similar curve when you look at data transmission speed and volume per $ over the same time span.

And then for storage. Going from 5 1/4" floppy disks, or effing cassette drives, back on the earliest home computers. Or the round tapes we used to cart around when I started working in the 80’s which had a capacity of around 64KB. To micro SD cards with multi-terabyte capacity today.

Same curve.

Does anybody care whether the storage is a tape, or a platter, or 8 platters, or circuitry? Not for this purpose.

The implication of, “That’s not Moore’s Law”, is that the observation isn’t valid. Which is BS. Everyone understands that that the true wonderment is how your Bang/$ goes up exponentially over time.

Even if you’re technical you have to understand that this factor drives the applications.

Why aren’t we all still walking around with Sony Walkmans? Because small, cheap hard drives enabled the iPod. Why aren’t we all still walking around with iPods? Because cheap data volume and speed enabled streaming services.

While none of this involves counting transistors per inch on a chip, it’s actually more important/interesting than Moore’s Law. Because it speaks to how to the power of the technology available for everyday uses is exploding over time.

I’m not sure if traffic is “convenience” at this point. At least where I live, it’s a nearly essential piece of functionality.

In fact, for local driving it’s often the only reason to use a map app. I already know how to get to most of the places I want to go, I just need to know the best route to avoid traffic now.

Yes, $15 CAD/day to “roam like home”. I have an Orange eSIM that I can keep alive if I use it at least once every 6 months - with a local french number that stays mine. It costs me about $40 CAD for a 30 day - 20GB top up. My wife uses Nomad for data only, we both don’t need local numbers, and it generally costs $12 CAD for 5 GB 2 week top-up.

So I figure about $60-70 CAD for 3 weeks travel virtually anywhere in Europe. Calls and SMS included (for one) without long distance charges. Compared to $630 for “roam like home” for two people from a Canadian carrier - doesn’t matter which one as far as I can tell.

We both recently got new phones to be able to use eSIMs.

And the physical SIMs stay active. So my elderly parents can call my Canadian number if there’s an emergency and it will ring through.

In fact, on our last trip to Rome, when we used a credit card at the hotel, it was refused and then seconds later I got a text from the bank asking for confirmation on my Canadian number. I had no choice but to text “Yes” back, and that single text activated roaming for the day and cost me $15.

I’m not buying that. Slavery has been a staple of civilizations all through history. There’s no universal law of nature that any being has any right to life, freedom or self-determination.

The “moral fabric” isn’t some universal constant either. It too is a function of society. In the U.S., for instance, in 1776 there was no moral problem with slavery. Time went by and morality in the country evolved such that slavery, for many, was no longer acceptable. But it wasn’t that the moral fabric of U.S. society was violated in 1776, it was just different in 1776.

Who knows, in another 100 years people might consider something that is normal today to be some huge violation of something that should be a human right.

Except, that many black folk in the US did not have a right to life or self determination at the beginning. So even these “inherent” rights aren’t so inherent until society agrees to grant/create them.

Not really. Rights are a man-made construct. A social contract that a people agree on. There’s nothing inherent about them.

A society could, for example, decide that certain people had the right to eat human babies, beat their wives. That would be just as legitimate as anything else.

By the same token, a society can decide that certain things are explicitly NOT rights, or to decide which rights take precedence over other rights.

None of this is defined by some divine ordnance, or law of nature. It’s all people.

From a practical perspective, I think that viewing SRP as referring to “direct” responsibility is good enough for making programming decisions.

Take the example from the Wikipedia entry. A module that compiles and prints a report. If that was split into 3 modules: one that compiles; one that prints; and one that delegates to the previous two modules to produce the output, then you would have achieved SRP. Yes, the third does two things, but it delegates them and is therefore not directly responsible for them.

At the same time this holds with the spirit of the official definition. Each module is only responsible to one source of change.

At a certain level of detail, your sources of change start becoming other modules and not users or Product Owners. Then it’s harder to think about SRP the “official” way. But direct responsibility is easier to make decisions on.

If I remember correctly, Objects were introduced in Turbo Pascal 5.5, not version 7.