> The idea that literally massive amounts of this workforce couldn't possibly be filled by domestic grads
One theory is that the benefit they might be providing over domestic "grads" is lack of prerequisites for promotion above certain levels (language, cultural fit, and so on). For managers, this means the prestige of increased headcount without the various "burdens" of managing "careerists". For example, less plausible competition for career-ladder jobs which can then be reserved for favoured individuals. Just a theory.
I think that would backfire as the intrinsic culture of the company changes as it absorbs more people. Verticals would form from new hires who did manage to get promoted
Putting aside economic incentives, which the wealthy were eager to reap, the vast majority of the technical labor force in this country came and still comes from (outside of SF) a specific race and we have huge incentives that literally everyone reading this has brushed up against, whether in support or against, to alter that racial makeup.
Obviously the only real solution to creating an artificial labor shortage is looking externally from the existing labor force. Simply randomly hiring underserved groups didn't really make sense because they weren't participants.
Where I work, we have two main goals when I'm involved in the technical hiring process: hire the cheapest labor and try to increase diversity. I'm not necessarily against either, but those are our goals.
People more concerned about getting a promotion than they are taking pride in doing quality work that makes a difference. Corporate rubrics for promotion have little to do with doing great work and careerists focus heavily on playing these stupid games set up by HR execs.
Former President Obama (of the US) calls this a "false choice". Can you be both focused on the next promotion and providing lots of value in your current role? I think the answer is yes. Of course, there are people whom seem to produce nothing, but get promoted... in the case of software engineers, they are mostly promoted on the principle of "competance" -- You are a good software dev... so now your run this team (regardless if they are a good manager!).
The compression effect in music amounts to increasing the amount of energy/loudness in the sound within the limits of the playback device to avoid "clipping".
Put very simply, it increases the amplitude of the input sound. Its parameters are controlled by internal timers, external triggers, timers and signals ("side-chaining"). For example; lowering the bass ("ducking") during the critical milliseconds of the kick-drum so that the volume of both can stay maximised while their sum stays within maximum amplitude.
On voice-over, in radio and podcasts it makes voices sound even and "boomy/strong".
Originally probably necessary way to make recordings listenable in cars and noisy environments with lower spec speakers.
Nowadays producers use it to "sound louder" and thus make stronger impressions.
Lookhead limiting is more commonly used to sound louder, not compression. Compression is usually done for flavor. It’s not that great at making things louder, because traditional compression actually exaggerated the spikes in amplitude at the start of percussive sounds, which pop and dance music has a lot of, requiring additional work to tame. Modern drum processing usually uses a combination of compression (sometimes with upwards compression), lookahead limiting, and saturation.
I suspect (in a common pattern) the main thing that blocks making performance a priority is that it equates to reordering various ranks among developers and product managers.
When performance supersedes "more features", developers are gatekeepers and manager initiatives can be re-examined. The "solution" is to make performance a non-priority and paint complainers as stale and out-of-fashion.
Probably more common is that software isn't developed with end-users as #1 priority; it's developed to advance business goals.
Those 2 goals align about as often as planets in our solar system.
To some degree this is true for open source software as well. Developers may choose to work on features they find interesting (or projects done in a language they feel comfortable with), vs. looking at user experience first. Never mind that optimizing UX is hard (& fuzzy) as it is.
Or all the work done on libre software to cater to various corporate interests. As opposed to power users fixing & improving things for their needs.
> are trying to organize group trips to sell to clients.
You might as well be saying "we are trying to make movies to sell tickets".
Organising group tours as such is easy, but the value is in the creative input that engages and inspires possible clients. Destination, people - both guides and participants, activities, materials are all part of this. It can't be "tested" just as two movies with the same synopsis can be completely different.
> Organising group tours as such is easy, but the value is in the creative input that engages and inspires possible clients. Destination, people - both guides and participants, activities, materials are all part of this. It can't be "tested" just as two movies with the same synopsis can be completely different.
Thank you for this input. I agree with you that the experience is the most important part.
We are preparing the first trip and will try to keep this in mind too.
We want people to go back home at the end with great memories and having met new friends.
We know we can't guarantee this to all but we'll try to insert activities and occasions to create community (probably not the best term to describe it).
The biggest success for us will be if people go back home with 7/8 new friends.
This is a bog standard travel package. So many of these exist and they are not difficult to produce.
Selling them (really) successfully usually revolves around some pre-existing brand tied to celebrities, authors, books that connect with the destination or theme.
Yeah of course we did not reinvent the wheel, but from our personal experiences, user interviews and searches this is not present at the moment in the Italian market.
> "Gym access, comfortable accommodations, sightseeing, custom meal plans"
These are general descriptions as we are in the steps of finishing the program of the first trip offered.
I'll update the article once we defined the program better.
We have a marketing expert to take care about the promotion and positioning, that is not my area of expertise. I'll forward the advice to him.
thank you, if you have any other advice please feel free to comment. Any piece of feedback can be very useful in this step.
Iirc the (probably simplified) LKH heuristic they used:
For each iteration:
apply some randomisation
starting at each place
cut the path in 2..n places
reconnect in the most optimal way
if the new tour is the new best, save
LK heuristic is a bit more involved, but focuses on continuing to reverse the subarray on the [b, ..., d] segment, with search and backtracking involved. (I think that's refered to as sequential k-opt moves, but I think it's already quite hard to know what exactly LK is, and LKH does much more)
By focusing on the subarray, assuming distance symmetry (length from b to e is same as length from e to b, but there are correct workarounds if this does not hold), you can evaluate the cost of the new route in constant time (but with bigger k there's more moves to evaluate https://oeis.org/A001171)
The compiler will complain about incorrect types and (?) infer types where possible. "Mixed" types are resolved at runtime.
There is a strict_types mode that will increase warnings/errors.
One of the problems with Pike is that the mechanics of this and other things are effectively undocumented so you have to learn by experimenting and reading the source.
No, python had already won by the time django and numpy started.
Pike's C interface is better in most ways, but of course that might depend on tastes.
Python's easy syntax, accessible documentation, books and tutorials make the learning experience completely different. It's an excellent choice for low-effort small scripts and short-lived projects. It became widespread. At some point it started to be the chosen language in schools. Numpy and django (etc) followed from that.
Pike with modernised syntax (something like Swift?) could have been a contender web-language maybe 2005-2006 at the latest.
Pike's learning experience was always less welcoming. The module tree reference is great though.
As long as inflation is higher than the interest rate, it means having to work less than an hour in total.
(But it's unsustainable in the long run ...)
reply