candu

Some ideas:

1. Prepare for meetings - set aside 10-15 min to go over any background info, agenda items, etc. Take notes as you prepare, so you can consult them during the meeting.

2. If something comes to you during the meeting but you don't feel comfortable raising it, write it down. You can always raise it 1-on-1 afterwards, do further research offline to answer questions, etc.

3. There are ways to contribute beyond ideas. Keep minutes. Help rein in digressions. Help bring attention back to salient points that got dropped. In general, communication is hard, and often requires both structure and diligence to be effective.

4. Given all this, if you're still not sure how to contribute to a meeting: do you need to be there? Some meetings are not an efficient use of everyone's time - maybe bring informed after the fact is good enough.

5. Consider raising your concerns to a trusted manager. A good manager is happy to help team members improve soft skills.

6. In that vein: talking and contributing are not synonymous. There are tools / approaches to conduct brainstorms that aren't rapid-fire talkfests: one common such structure is to give team members time to independently write down thoughts, then review afterwards. Keep in mind also that the person who says 1 or 2 well thought-out things is likely contributing way more of use than the person who insists on adding their opinion to every last item.

HTH!

Yeah, I wish that science reporting would either a) mention specifics on methodology or b) link directly to papers.

Without this plus a stronger push for open-access publishing, readers often have absolutely no way to verify claims like this - and, moreover, have no way to learn how to apply similar methodologies to their own work. There's a lot of people in data science / analytics positions right now who could benefit from sharing knowledge around statistical tools to correct for highly unusual situations.

...except that, in said dark ages, that got people executed for treason or witchcraft or what have you.

Here, it could very well save lives. Many democratic governments have tried voluntary restrictions - some people are complying, but others don't seem to care. What else is there but to enforce those restrictions via previously existing channels (e.g. Quarantine Act in Canada)?

IMHO, this is similar to reporting someone for smoking near a public building, dangerous / drunk driving, or any of a number of public health / interest infractions.

Also in Canada here, albeit the big-city part - our telecommunications sector is uniquely bad in terms of bandwidth / service for value and consumer choice.

We have organizations like Internet Society Canada (https://internetsociety.ca/) that are aiming to help change that, but it's an uphill battle.

OTOH, I'd love to see the mental / rhetorical gymnastics demanded of our politicians to defend tech companies from large fines associated with privacy violations while simultaneously excoriating those same companies over privacy violations.

There's an assumption here that one can easily self-learn to self-study.

It might be true for some proportion of HN readers, but it's not clear that this generalizes. After all, those of us who self-study are often learning programming-related topics for which there is both abundant online documentation and clear, objective feedback on progress. We also tend, as a community, to have reliable access to the necessary technology, large amounts of disposable income (and security of leisure time that comes with it), a high level of prior expertise, and exposure to role models in self-learning. It's easy to take these things for granted, but they all certainly help in developing self-study habits.

As much as I might personally like to see everyone be more self-driven and self-reliant in learning, I share the concern expressed elsewhere in this thread as to what the impact of a sudden shift to remote learning would be on equitable access to education.

Speaking as someone with Asperger's who considers himself both a good programmer and capable of navigating / leading cross-functional prioritization discussions, and who likes knowing the context behind his work: maybe you should re-evaluate your assumptions about neuroatypical people.

(...and if you're indeed in a position where you're responsible for hiring decisions or performance reviews: strike "maybe" from the preceding sentence.)

This is a great point in general: sometimes the problem isn't an adversary using knowledge in your field against you, it's the unintended consequences of progress / changes in adjacent fields.

It also underscores that, when dealing with things like passwords, it's helpful to be able to seamlessly upgrade to more robust methods down the line, e.g. "if this password hash was generated using the old method, check the login using that method but rehash and update the database using the new method after authentication."

IMHO it's a good idea to learn things at different points on the adoption curve - learning to balance "cutting edge" with "already widespread, I just haven't used it" helps in making good judgments about tool selection for projects.

Reactive component frameworks: I've been quite happy with Vue. I'm interested in learning Svelte - don't know if I would use it for production yet, but it's definitely gaining traction and has some interesting ideas. (The compiler-based approach makes a lot of sense, especially with wasm on the horizon and the desirability of cross-compiling to native mobile platforms.)

Visualization / mapping: Mapbox GL is amazing, to the point where I can't recommend Leaflet anymore; the only major hurdle is their style spec, which makes a lot more sense if you have some exposure to LISP-like languages. AFAICT d3 remains the gold standard for interactive visualization, and the micro-library approach of v4 / v5 means you can take advantage of things like webpack tree-shaking. I'd love to play around with Observable notebooks as an alternative to Jupyter.

Databases: PostgreSQL + PostGIS. If you aren't _deeply_ familiar with the many awesome features of this combo (vector tile generation via ST_AsMVT, functional indices, full-featured JSON support, transactional DDL, etc.), take the time to become familiar; there's a good reason SQL is the new NoSQL :p

Other things of personal interest, in no particular order...I'd love to learn more about HTTP/2, GraphQL, wasm, ways of organizing CSS, and ways of organizing ETL / automation pipelines. For languages, I'll usually run through tutorials every now and then to get the feel, but other than that I largely take a "just-in-time learning" approach.

The thing that jumps out at me about HTTP/2: even if your browser can send N parallel requests for different entities, you're still making N database queries and incurring N request overheads.

This means that every layer of your stack has to be reorganized and optimized around HTTP/2 traffic patterns...or you can just batch requests as before, and save that overhead. It makes me think that the N entities problem isn't actually the most promising use case for HTTP/2...

Similar to many of the other comments here: you should figure out what "success" means to you. It's easy to make the default assumption that success means lots of money and long working hours, at which point you've defined success in opposition to work-life balance. (Not that it's necessarily wrong to do so, but I'd contend that it is problematic to do so without explicitly deciding that this is what you want.)

I'd estimate I work 40-45 hours most weeks, with occasional bursts of 50-55 hours pre-deadline often compensated for by shorter weeks afterwards. The popular myth of insane working hours aside, this is actually pretty normal [1] in our industry. I get to work with awesome people on projects that I care about, I earn enough to live comfortably but not lavishly (as do many people in this industry), and I have enough time / energy left over to enjoy hobbies, friends, and travel. I also get to learn continuously and enjoy reasonable latitude / autonomy in decision making.

To me, this means I've been pretty damn successful. Could I have more of these things I've described? Possibly, though maybe not more of all of them at once. Am I living the hyper-optimized best possible version of my life? Arguably not, but it's also not clear to me that this exists; all important choices involve tradeoffs, and what's optimal now may not seem so to 5-years-later me. Personally, I've found it healthier to accept that my definition of success has changed and will change further, and that finding success is maybe not as important as searching for it :)

[1] https://insights.stackoverflow.com/survey/2019?utm_source=so...

To add to this: a common problem with these projects is that, even though the requirements are vast and extremely hard to pin down, stakeholders insist on pinning them down up-front anyways because that's how it's always been done.

This is then compounded by a procurement process that sets these requirements in stone as fixed deliverables, as opposed to offering both sides the flexibility to reassess after interim sprints / milestones / etc.

Fortunately, groups like GDS [1] in the UK, CDS [2] in Canada, and 18F [3] in the US are helping shift this mindset slowly but surely. That's where you get initiatives like agile procurement [4]. Procurement aside, these groups are also at the vanguard of introducing modern tech stacks / tools, user-centered design, and agile project management to the public sector. (Yes, these things exist in government, and these groups are really passionate about making sure their adoption goes beyond mere buzzwords.)

Side note: many of these groups are continually hiring, and they've been around long enough by now - and had positive enough results - to gain some clout. If you're tired of selling eyeballs to advertisers, there's never been a better time to use your skills in service of the public good. It doesn't have to be a "lifer" thing - CDS, for instance, has a number of 2-year rotating positions.

Source: I'm an ex-fellow with Code for Canada who's continuing to work in the public sector :)

[1] https://www.gov.uk/government/organisations/government-digit... [2] https://digital.canada.ca/ [3] https://18f.gsa.gov/ [4] https://www.canada.ca/en/shared-services/corporate/doing-bus...

The point here isn't about structured vs. unstructured logging: it's about addressing the possibility that legitimate users get blamed for theft.

This sort of dispute is probably going to end up in a legal forum at some point. In that case, video footage from a device that's not physically on the bike (and therefore much harder to tamper with) is going to carry much, much, much more weight than GPS traces. Also, you usually know exactly who is supposed to have access to CCTV camera systems / footage, and can therefore have those people make legally binding representations as to their accuracy / fidelity.

(Of course, with regards to this problem, your objective as a service provider is to end up in court as infrequently as possible. You'd be more likely to invest in anti-theft measures so you can get the probability of theft low enough to reasonably write off as part of opex.)

Not sure how they do it exactly, but one possibility is CCTV cameras watching drop-off locations. You can then compare footage at the timestamp it was reported on-location if there's a dispute.

Combine this with a few anti-theft procedures that don't involve GPS / internet (as commonly used by bikeshare programs in various municipalities) and you've got something that might work.

...which is the value of robust systems designed to limit the impact these people can have.

This is precisely why mechanisms like separation of powers and whistleblower protections matter. This is also why social conventions around honesty, reciprocity, fairness, etc. matter.

When these mechanisms and conventions operate smoothly, you get a sort of "security in depth" against abuse and exploitation. People acting in bad faith find their worst impulses thwarted, both by societal / legal systems and by average citizens who are empowered to help hold them to account.

When they don't, you get dangerous patterns of corruption and indifference; these weaken trust in the system, making it harder to fix over time.

From [1], a terse one-liner that outperformed many longer and more complicated entries in The Second International RoShamBo Programming Competition:

    int henny() {
      return((*opp_history?opp_history[random()%*opp_history+1]+1:random())%3);
    }

[1] https://webdocs.cs.ualberta.ca/~darse/rsbpc.html

This particular argument? Not as phrased, no.

The main point often raised around the right to bear arms is that, as currently interpreted in the US, it comes at a steep cost in homicides and suicides.

Encryption doesn't really have comparable collateral damage in society. There's the whole "but terrorists and pedophiles will hide behind encryption" argument, but even if you granted that and could measure the impact, there's little chance it would be anywhere near equivalent to 30 000 deaths annually.

So: a more nuanced version of this argument would point out that there's little to no harm from allowing widespread strong encryption, whereas there's widespread demonstrable harm from allowing widespread firearms.

To compound this, the reverse harms - lack of privacy / security on one hand, strict monopoly of force on the other - are hard to compare. Both have the potential harm of leading to unchecked tyranny, along with the potential benefit of maintaining national security and civil order; depending on which side of the debate you're on, the tendency is to downplay either the harm or the benefit and exaggerate the other.

Any reasoned comparison here ought to take into account that the tradeoffs are clearly different.

Don't have separate get / set functions?

    async function changeBalance(account, amt) {
        /* 
         * BEGIN;
         *
         * UPDATE accounts
         * SET balance = balance - amt
         * WHERE id = ${id};
         *
         * COMMIT;
         */
    }

Of course, this is just a mutex in database transaction clothing :)

Your general point is solid, but one quibble with the numbers - even the pricing page has an "enterprise" tier "for very large businesses".

There's no way a company with 5000 Slack users is paying the sticker price per head - they'll call Slack's enterprise sales team and negotiate some volume discount with whatever shiny enterprise-grade features, SLAs, support guarantees, etc. they need.

It's almost as though...we as a society continually assess whether the harm from some activity exceeds benefit, and react accordingly?

Or maybe we're starting to expect that people building things have responsibility to foresee potential harms arising from their use, whether or not part of the intended use case, and to build in an equitable way?

After all, if "inadvertently deepens abject poverty" is a possible outcome of a tool you're building, maybe the problem is with the design and not the people using it.

Fair point: sometimes things are, in fact, bad enough that a rewrite is warranted. IMHO, this is where the "senior engineer" mantle becomes less about engineering and more about interpersonal / organization-navigational skills.

Let's say I'm a manager at said company. An engineer who just joined my project - which our previous senior engineer, who I trust (fairly or not), built - tells me it needs a complete rewrite. My default reaction is likely skepticism: the received wisdom is that rewrites are seldom justified; your assertion contradicts both this wisdom and my previous senior engineer. What do you expect my answer will be?

As the engineer making this recommendation, you'll need to do a bit of showing why. Part of this is technical: write some tests that show the problem, quantify the data loss, etc. Show that you've carefully balanced rewrite vs. other more incremental approaches to fixing the problem. Prototype part of a newer system quickly and show that it can be done.

The harder part to motivate - and often the more important part when it comes to "how do I get people to say yes?" - is non-technical. What's the business impact? What's the user impact? Is this an existential risk to the company if not fixed? How so? How do we assure our clients / users / etc. that time spent here is more important than time spent on features they want? Can you get someone with significant decision-making power to agree? How will you de-risk the rewrite and eventual migration, neither of which are trivial? How can you get just enough buy-in to secure the time needed to answer these questions, show quick progress, and reassure others that this won't be an even bigger catastrophe?

For database testing, I often use a "ramdisk", or in-memory filesystem: sudo mount -t ramfs -o size=512m ramfs /path/to/mount/point, initdb, pg_ctl start. (There's a bit more bookkeeping to generate passwords, store them to /path/to/mount/point/.pgpass, etc.) You can tear it down afterwards with pg_ctl stop, sudo umount /path/to/mount/point. I'll put the necessary commands in start / stop scripts, then call those from within the beforeAll / afterAll hooks of whatever testing framework I'm using.

It's definitely slower than mocking, and therefore not really suitable for unit tests - but it's great for repeatable, isolated integration tests (continuous or otherwise).

Perhaps...people are assessing this offer and deciding it doesn't, in fact, have strictly better expected value? The prevailing wisdom is that equity grants have an expected value near zero.

Once the prospective hire also factors in the common startup expectation that you sign over all your waking hours to the company, the surprisingly substantial value of benefits, and the added risk that the startup goes belly-up or can't make payroll regularly at some point, that offer of matching salary starts to look much less attractive.

Not saying that your frustration isn't warranted, or that all of these factors necessarily pertain in your startup - just that there are entirely valid reasons why the person on the other end of the table might refuse. (After all, the thing that makes much of modern economics / commerce possible is that risk is subjective.)

Have a home garden, don't really use much of 1) or 2), and we get enough rain throughout most of the growing season that usage of 3) is pretty light - on the order of "we water the garden for 1-2 minutes once every 2 weeks or so, and it's fine". (I don't have precise figures to attach to these.)

(More on 1) - we do use Jiffy planters for some things, which we then rinse after transplanting and reuse the next season. However, we mostly sow directly outside.)

There are a few things missing from this comparison, though!

First and foremost: impact of shipping. Once you ship zucchinis from Mexico to your local grocer / supermarket, there's a lot more embodied carbon than in a zucchini you pulled from your front step.

Second: mechanization. AFAIK, most home gardening is a pretty manual process. Not so for industrial-scale farming, which involves tractors and tillers and spraying planes and giant irrigators and so on. While there is a bit of "amortization at scale", those all add to the total lifecycle resources necessary to grow something. (Not to mention that all that equipment has to be built somewhere from materials extracted somewhere else, and the ongoing maintenance cost / burden of this equipment is decidedly higher than for our push mower or pruning shears.)

Finally: land use. Most farmland was (either recently or historically) cleared from forests, which are also giant CO2 sinks. The most prominent example today is probably heavy deforestation in the Amazon, mostly for agricultural and meat production. Now, of course our home garden sits on previously cleared land, but we're not clearing any more of it - in fact, we have trees, bushes, ground cover, etc. in parts of our garden space, meaning that we're taking what was underutilized urban land and converting it to a CO2 sink.

I'd love to see a scientific lifecycle analysis of gardening vs. agriculture, along with guidelines for "environmentally responsible gardening" - but I'd be very surprised if the analysis didn't come out heavily in favour of local small-scale gardening.

Ah - the goal is not necessarily the choice / freedom of readers, but that of other writers who might be drowned out, intimidated, or otherwise coerced into silence.

When this happens across a large and popular enough cross-section of media, though, it could easily start to have a noticeable effect on readers.

Among other things, it enriches private prison operators through exploitation of indentured labour, disproportionately incarcerates low-income / racialized people on non-violent drug offenses, costs the average US household nearly $1700/year, leads to high recidivism rates, and dovetails with the growing militarization of police forces. [1]

But hey, at least it feels good to some people on a visceral level! Those world-leading incarceration rates won't maintain themselves, you know.

As a non-American, I'll never understand the cultural cognitive dissonance in simultaneously trusting the government to be "tough on crime" - despite all evidence that this approach backfires strongly - and distrusting their intervention in just about anything else.

[1] https://en.wikipedia.org/wiki/Incarceration_in_the_United_St...

...and now we've touched on a fundamental philosophical question: is freedom of speech a natural right or a legal right?

There's also potentially an assumption here that free speech is overall reduced through restrictions on it. As a thought experiment: suppose that, within a society of _n_ people, some small _k_ of them are "louditarians": they believe that part of the right to free speech is the inalienable right to speak as "loudly" as possible (for whatever value of "loud" matters over various media) so that no one else can effectively speak. This raises a few difficult questions:

1) To what degree the free speech rights of louditarians and non-louditarians mutually exclusive? 2) If you were a non-louditarian in this society, what would you do? 3) If you had control over this society, would you let the louditarians speak? Would you limit their speaking rights?

My general position here:

1) Almost entirely: when louditarians speak, they prevent the effective exercise of free speech rights by non-louditarians; non-louditarians can only meaningfully have free speech if louditarians are carefully managed. 2) As a non-louditarian, I'd advocate for limits on louditarianism (as best I'm able; this may first require the creation of non-louditarian-only spaces where I can be heard). In the absence of those limits, I'd probably feel like I was being effectively silenced by louditarians. 3) This is the difficult one, and I lean towards "yes - reluctantly, warily, and with limitations". Some examples: maybe louditarians can only speak at certain times (see: nighttime "disturbing the peace"). Maybe the practice of louditarianism is banned from certain spaces, like offices and legislative chambers (see: contempt of court, noise bylaws). My reasoning is utilitarian: I'd rather _n - k_ non-louditarians be able to speak, even if that means curtailing the rights of _k_ louditarians.

In other words: I strongly believe that, by imposing limitations on louditarians, I'm increasing the overall freedom of speech in this hypothetical society. (Not to mention the quality of life, mental health, and vitality of public discourse.)

My secondary reasoning is that louditarians seem to think that speech is a right without responsibilities - in effect, they believe that their right to free speech is more important than that of non-louditarians. IMHO, this violates the social contract of functioning modern societies, and for what? So an obnoxious fringe group can be really, really loud?

I've seen both opinions, and many more nuanced variants thereof, argued in a well-reasoned, persuasive manner here on HN.

Adding my voice to the "good riddance" side of the aisle: thanks to what freedom of speech, association, etc. actually mean in the legal / constitutional context, said twats are guaranteed a space for communication - the real world! They can stand on a corner or picket their local City Hall and spout all the hateful nonsense they want.

(They can't, however, verbally assault bus drivers / police officers, or yell "Fire!" in a crowded theater, or directly incite violence, or disturb the peace at all hours of the night, or needlessly interrupt judicial / civil proceedings, or...point being: even in the US, the exercise of free speech comes with limits and responsibilities.)

Like publicans of yore banning rowdy drunks from the premises (which itself came with political / legal overtones; see https://www.amazon.ca/America-Walks-into-Bar-Speakeasies/dp/...), many owners of online spaces are deciding - as is well within their rights as owners of a private space - to ban users and groups who disproportionately degrade the experience for all others.

(This is my general surface-level opinion, without getting into discussions like https://gimletmedia.com/shows/reply-all/rnhzlo around the amplification of extreme voices by short-sighted metrics optimization, or debates on whether providing space for hateful voices effectively denies free speech to the targets of their hate, or explorations of the tradeoffs different open, democratic societies have made around hate speech.)

IMHO, this means the average driver shouldn't be driving in cold, wet conditions.

If you're going to use something that can kill people if mishandled, you take on a lot of responsibilities, one of which is to maintain attention / control.

Same goes for many such objects, really: power tools, guns, industrial machinery, medical equipment, etc.

...no, but it bears remembering that many cities in Europe were effectively bulldozed by two world wars, not to mention centuries of smaller wars.

Just because you can raze entire cities, displace their populations, and embark on "clean slate" urban planning projects doesn't mean you should. That's the civil engineering equivalent of rewriting the entire codebase from scratch.