astockwell

I literally laughed out loud at this. Well done.

Thanks for your comment, how long have you been at it?

Edit: Saw your note below > "150+ lbs, the past decade"

Any resources you would recommend?

The attitude of complex, manufactured things that require extensive mining and refining infrastructure and include uncommon elements (literally, molecular elements) being single-use is awful. We need to hold ourselves to a higher standard.

One thing I took away from being on-call at a company with lots of outages/incidents: management allows those outages. I know that sounds weird, but if there are constant lights-on problems, but every day management is prioritizing features/other work, the management is demonstrating that those outages are tolerable to them. Once I got my head around this, I stopped jumping-to at 3am like the world was ending for every single incident.

That is terrible, hang in there! The silver lining is that you trusted yourself and it led to the truth, which is now exposed. Keep trusting yourself and you will make it through.

The first time I emailed a buddy a Go cross-compiled binary and he opened and it ran no problem (opsec aside), our worlds changed.

As an American living in Ontario, Canada for a time, I literally COULD NOT BELIEVE the gig economy there. It is what the US aspires to: a guy owns a snow plow business, employs 30 other gig workers 6mos a year. A woman does city/house hunting tours. Contractors are consistently self-employed. On and on. These folks, earning enough to live, and (to another commentor’s point) without fear of medical bills/issues. That really is it: that’s the difference. And it makes all the difference.

I am trying to help a Windows-using team ramp-up on Go dev, and it's pretty rough.

Currently my advice to them is ditch VS Code and download GoLand, the editor change is jarring but the experience is much more fluid on Windows overall. Also transparent support for modules, per project.

For compiling when your code (or a package you're using, e.g. sqlite) has a cgo dependency - afaik YES you will need to go down the dark road of cygwin/Mingw, if you want your development cycle to be at all normal... and even then, my observation is compilation times are an order of magnitude slower on Windows :(

At GopherCon I met folks who worked for huge, "old guard" Windows companies who said "just run a linux VM" to develop in Go.

If you just need to compile for windows once and a while (e.g. for releases only, not as part of your normal dev cycle), check out xgo [1], which uses docker to deal with all the cgo mess. No cygwin/Mingw to install/worry about.

Best of luck! If anyone else has tips for working in Windows, I'd also love to hear them.

[1] https://github.com/karalabe/xgo

Discipline equals Freedom, no doubt

Ahh thanks for the great explanation! Love HN.

> Allocate capacity in make to avoid re-allocation

Am I the only one who has done this and used append() within a loop, and resulted in a slice that is 2x as long as the original desired length, and the first 1x of items are all empty?

I quickly caught it and fixed the approach (instead of append, I used the `i` as the insertion index into my new empty slice which already had capacity allocated), but the ease with which that subtlety could be overlooked turned me off to this approach unless I profile and really find it's a hot path.

Edit to add: I tried his code, and it resulted in the new slice being as expected.

This is completely untrue.

I'm an American citizen and not a single one of the 6+ W2 jobs I've held have quoted the base salary with insurance premiums deducted.

This. The American urge to compare only base salaries (because that's all you have in America) is why Americans don't understand what they're missing. It's not in the salary! Its in the alleviation of $1000/month medical insurance premiums, in addition to $4000 ER visits (inclusive of said insurance), and pensions.

And before someone bemoans the taxes, let me clarify that those medical premiums and ER visits are AFTER-TAX dollars, so add an additional 15-30% on top.

Man oh man. Having (loosely) followed this saga, it sounds horrifically similar to every other "feature rush" I've ever seen in software development. I know this a fiction, but I can just imagine the scene - boss comes into SWE meeting, says "some other team implemented this thing that the higher-ups wanted, we have to change all of our stuff to make it work, and we only have X weeks/months" (common sin: deadlines before effort estimates). Then more issues are discovered in dev, SWE's try to push back but are ignored (common sin: concerns are not heard). "Scope is reduced" (common sin: this ALWAYS happens with hard deadlines, but SHOULD NEVER happen with human safety involvement, although it still does all the time e.g. healthcare).

It's not until some poor, senior engineer, who is probably one of their best staff, has a stellar reputation, and genuinely cares about their job, their team, the product, and the company ... they have to fall on the sword and TELL management what's going happen: we're not shipping this yet, IT IS NOT SAFE. Then that goes all the way up the chain, management at every level wrings their hands, "how oh how did this happen?" (although they specifically are talking about the missed deadline, not the safety concerns). It gets high enough that feeling is overcome by senior leadership wrath, which flows back down, and ultimately that engineer and their entire team is punished.

What a dumpster fire.

> Yes there's a hardware camera. I will bet some money that they have not been used nefariously

Talk about the tag line for the past decade.

Would love to see a "whole system in more detail" write-up!

Because we have 40+ years of concrete first-hand evidence that it does not.

A Book Apart [1] has an entire collection of short books on UI/UX topics written by industry pros.

[1] https://abookapart.com

Is there a decent convention for naming your specifically-for-deps module?

‘go mod init vendored’?

What do you mean by paper trading account?

As others have mentioned: app.min.js?$hash-or-date-or-releasever$

I'm the only person on my current team (an internally-focused engineering team) who has experience building websites/apps for external paying clients (e.g. people who will freak out if anything fails to load faster than they can blink, on their phone's 3G connection).

I was taken aback by how many times I had to argue with my team, our sister teams, our consultants/contractors, and even our (non-technical) leadership about NOT building a SPA when we came across 1 form in our large codebase that required some extra interactivity.

For some reason many developers seem to be fine turning a blind eye to the actual page-rendering time, maybe because it's hard to benchmark with tools? (although I'm skeptical of that). I find an overlap however in that those same developers seem to not understand why multiple database query roundtrips are worse than 1 query followed by some in-memory munging.

I'm sure I'm biased by my background, where we were profiling like mad, doing crazy things like purposely modifying images/hand-building sprites to pack better, minifying CSS before SASS/LESS existed, and every millisecond to finish rendering mattered. Good times.

Trauma can be a rapid gateway to addiction, but it’s not required. The brain will seek to repeat anything that brings with it a happy shot of dopamine.

Not on any post-2015 models.. :(

I toiled like you seem to be for a long time, cleaning up technical debt, and writing well-architected (but very time-consuming) code. I learned a few things (things I have to remind myself of often, when I too feel the anger rising at people who don't place the same priority on those things):

The business is almost never paying to you clean up technical debt. They are paying you to generate revenue (or save costs). Period. It could be the best architected system in the world, but if it takes 4x as long to build, and the "quick and dirty" version can ship and generate revenue earlier, then that is the way the business will want to go (even with an elevated error/loss rate). My takeaway: If you do not intimately understand exactly how what you do each day makes the business more money, or saves the business more money, then you need to pause and figure that out.

Nobody gets credit for building a system that never goes down. It does not speak for itself (much as I would like it to). As others have pointed out, it's critical to communicate the value (see point above) of what you are doing, and communicate it to the people who matter.

Dealing with Humans (incompetent and otherwise) is actually what most of us get paid for (or at least it's a big share of why we get paid). Dealing with bureaucracy, red tape, incompetence, things taking too long, etc... Sometimes I wonder why I have to wait for others who are slow, don't they realize how much money is being wasted?! But it's true, the human component of our jobs is the main reason why we haven't already been replaced by others/computers. Relationships trump even adding business value (point 1 above): if you are difficult to work with, but add value, you will still be marginalized (or even let go). However on the flip side, if you are great to get along with but do little-to-nothing, you may not thrive, but you will survive.

Good for you, +1 to the greater good for your sacrifice.

Tangentially related (and an absolutely shameless self-promote): a colleague and I recently described a repeatable approach and methodology (including example) for malware deobfuscation in a recent conference talk. Full narrated video of the talk is here [1], deobfuscation portion is roughly the middle third.

[1] https://youtu.be/RAtjW7PVGaM

IIRC they define their customers as other internal teams, separate from external customers, who (I'm guessing) are handled by external product teams.

OH! And json-to-go people, use json-to-go. Thank me (well, mholt really) later!