Not enough to move the needle. 25% would move the needle.
> with mentions that I could double it in one year
They didn't believe you, or didn't after a short time working there. So it didn't move the needle.
More so if they're experienced. Similar mentions of prospects are common in interviews, and rarely followed through. You eventually learn to be skeptical of them, while rolling with it, just in case.
Also, if you might be willing to pay double their requested salary, they start realising their value on the open market is much higher than they'd previously thought, or could be with a little presentation and experience.
On the other hand, if you'd put it in the contract that their salary will double after 1 year, subject to well-defined criteria and a history of actually doing it with existing employees, then they'd believe you, and that would move the needle a lot.
From your story I speculate you were right to fire them, but you never figured our how to get the best out of them. In recent years it's possible you were subject to employment fraud, as clarity of analysis can disappear if it's a different person doing the work than the person answering interview questions.
Progress that's entirely stalled or negative can happen for many other reasons than moonlighting, and many other reasons than not putting enough time.
When Chrome was released, the advertising I recall focused on one killer feature that Firefox didn't get for many years after that: Speed.
Chrome's JIT JavaScript was so much faster than everyone else's interpreted JavaScript that you could run a materially different kind of software in the browser. It was like the difference between a slow interpreted language and a fast compiled one. Chrome's rendering was also fast.
There was even a cartoon explaining how the new JavaScript engine worked.
Chrome felt like the next generation of browser.
I say this as someone who remained a fan and user of Firefox throughout. I stuck with Firefox through its relatively slow years.
Firefox caught up, but it took years. It got its own JIT JavaScript, but there were a few years after that where Firefox's rendering was relatively slow by the new standards. However, Firefox has excellent performance all round by now.
I was disappointed when Chrome came out that JIT JavaScript could even be a marketable feature and wasn't already the default in the best open source browsers, because it seemed like such an obvious thing to do for many years prior, and not particularly difficult. I guess market forces resulted in nobody deciding to do it in Firefox, or any other open source browser, until competition made it a necessity. I was quite surprised, because Firefox seemed like the product of passionate technology nerds, and performance JITs are very fun and satisfying things to make, with visible results.
> When Chrome was released, the advertising I recall focused on one killer feature that Firefox didn't get for many years after that: Speed.
And sandboxing. Browser sandboxing was rare due to the memory required, and Chrome released right around when it started being practical to run tabs in separate processes.
> $1700 per month pays off a $350k loan in 17 years, does it not?
No, it does not. You forgot the interest. Let's call it 6%, close to the current US average.
The interest by itself comes to more than $1700 a month!
Paying $1700 per month, you'll never pay off $350k, even with a 1000 year mortgage.
To pay in 17 years, you'd need to pay $2741 (plus fees) per month. Most of that will be interest at first, but it tapers down. If you want to start out not paying mostly interest, you'll need to pay at least $3500 (plus fees) per month.
The parent I was replying to stated a $70k deposit on this, meaning it would take about 25 years, so my early morning maths was a bit off. Even so, that doesn't seem unachievable?
Yes and no. A lot of people have gaps in their financial education.
That said, mortgages aren't rocket science.
1. Assume at the end of the day you want the homeowner to be paying a stable monthly amount*.
2. In order to get there, you have {loan term}, {interest rate}, and {loan amount} as primary variables.
3. Assuming {loan term} and {interest rate} are constant (in a given mortgage market, at a given time), that leaves {loan amount} as the only variable.
So how do you get a constant monthly payment for a variety of {loan amounts}?
4. You add up all the interest that would be owed over the entire {loan term}, using {interest rate}, then divide each monthly payment into some proportion of {interest payment} and {principle payment}.
5. You also front-weight the interest payments, because at that time there's more outstanding total loan (versus at the end of the loan term, when only a little principle remains to be paid back).* *
Not super complicated. Yes, there's compound math, but conceptually simple.
* For some definition of stable, even if it readjusts on some schedule
* * Point in time interest pricing like this also makes future recalculation for over/underpayments easier, as you're essentially trued-up on interest payments at all times
If the original develoeprs had used Git, they'd be mostly fast-forward merges. Those are the default merge operation in Git, and they don't appear as merge commits in a repo.
However, there commits start 33 years before Git was created. Merge commits were not even a concept back than.
> For example, suppose you allocate 1000 page sized objects and then free all but the last one. With an mmap based heap, you can free all 999 other pages back to the OS whereas with sbrk you're stuck with those 999 pages
Actually... you can free those 999 sbrk() pages using munmap() on Linux and Darwin (so most likely the BSDs too). You can also change the mappings within the sbrk()-allocated range, much like any other mmap.
This feature is not well known, nor particularly useful :-)
> /usr/bin/env and /bin/sh are part of the POSIX standard, this is why NixOS has those available.
Contrary to popular belief, those aren't in the POSIX standard.
The following are not in the POSIX standard, they are just widely implemented:
- "#!" line.
- /bin/sh as the location of a POSIX compliant shell, or any shell.
- /usr/bin/env as the location of an env program.
- The -S option to env.
I think you are using "not required by the POSIX standard" when you say "not in" which is not an accurate shorthand.
#! is certainly in the POSIX standard as the exact topic of "is /bin/sh always a POSIX" shell is a discussion point (it is not guaranteed since there were systems that existed at the time that had a non-POSIX shell there)
Are they in POSIX? I do not think they are. All of them is a convention from what I remember.
Shebang is a kernel feature, for example, and POSIX does define the sh shell language and utilities, but does not specify how executables are invoked by the kernel.
Similarly, POSIX only requires that sh exists somewhere in the PATH, and the /bin/sh convention comes from the traditional Unix and FHS (Filesystem Hierarchy Standard), but POSIX does not mandate filesystem layout.
You're definitely correct. "#!" is reserved (see Rationale C.2.1), but not required, though it's described as "ubiquitous" (see Rationale C.1.7). "/bin/sh" isn't required either, but arguably ubiquitous in that there's always some shell located there. The proper way to find the POSIX-conformant shell is with `command -v sh` (which is equivalent to using `getconf PATH` and then searching for sh), and POSIX counsels to discover the path and substitute it inline when installing scripts (see Application Usage in sh utility specification.)
IME /bin/sh is invariably sufficiently POSIX conformant to bootstrap into a POSIX shell (or your preferred shell), even on Solaris and AIX. And if you're willing to stick to simple scripts or rigorously test across systems, sufficient for most tasks. Outside Linux-based systems it's usually ksh88, ksh93, pdksh, or some derivative. OTOH, for those who are only familiar with bash that may not be particularly helpful.
I've had more trouble, including bugs, with other utilities, like sed, tr, paste, etc. For shell portability it's usually niche stuff like "$@" expansion with empty lists, for example how it interacts with nounset or IFS, independent of POSIX mode.
Sometimes the harm is severe. Vast oceans of poorly handled personal data collected in exquisite and unnecessary detail by dark patterns, copied around to everyone who might be interested with low regard for security, kept forever, analysed by the best algorithms and sold to whomever will buy it, raise the risks and consequences of identity theft and fraud for everyone.
Those are the sorts of things GDPR is designed to limit.
The GDPR isn't about cookies or websites. It applies to non-web-based businesses too. It's basically just insisting on security best practices in every part of a business that handles personally identifying or sensitive data.
Limiting its collection to what is necessary and consented to, deleting or anonymising it when it's no longer required, respecting wishes of the individuals the data, and giving people some confidence that security best practice is taken seriously.
Many of the people who "don't care" don't know. Once you inform people about how much data meta has on them, for example, many of them do in fact care and they are in fact disturbed by it.
Now, they tend to continue to use meta's products because they have become essential communication tools for those people, so in fact, many people would welcome regulation that allows them to continue to use key communication tools without the sleazy privacy violations they weren't aware of.
> Most people don't care about these things. Who are you to say that the harm is severe to people who don't care?
I'm not the one deciding.
I said some of the harms are severe. Not everything. It refers to things like people losing their online accounts, having their bank account drained, their credit rating ruined, private photos shared, passwords changed or published, losing files to ransomware, all as an indirect result of poorly handled data collection resulting in identity theft and similar.
I'm pretty sure most people affected by those things do consider them severe, and that many people upon learning about those things also consider them quite severe, even if they didn't care before they learned.
If most of those people consider those things severe, that's enough to call them severe.
It's a measure of time spent working on something, to standardise comparisons of work capacity and acknowledge that it's not always full time, especially when aggregating the time from different people. One full time person = 1 FTE.
For example if you work 20 hours a week on project A and 20 hours on project B, then project A will count your contribution as 0.5 FTE while you're assigned to that project.
If you also have two other people working on it full timee, and a project manager working 1 day a week on it, then project A will count the contribution from all three of you as 2.7 FTE. (2.7 = 0.5 + 2 + 0.2).
This example assumes 1fte=40 hours which is not nexessarily the case in all countries or under all collective agreements. 1fte can be 36, 38, or even 48 hours.
Not enough to move the needle. 25% would move the needle.
> with mentions that I could double it in one year
They didn't believe you, or didn't after a short time working there. So it didn't move the needle.
More so if they're experienced. Similar mentions of prospects are common in interviews, and rarely followed through. You eventually learn to be skeptical of them, while rolling with it, just in case.
Also, if you might be willing to pay double their requested salary, they start realising their value on the open market is much higher than they'd previously thought, or could be with a little presentation and experience.
On the other hand, if you'd put it in the contract that their salary will double after 1 year, subject to well-defined criteria and a history of actually doing it with existing employees, then they'd believe you, and that would move the needle a lot.
From your story I speculate you were right to fire them, but you never figured our how to get the best out of them. In recent years it's possible you were subject to employment fraud, as clarity of analysis can disappear if it's a different person doing the work than the person answering interview questions.
Progress that's entirely stalled or negative can happen for many other reasons than moonlighting, and many other reasons than not putting enough time.
reply