gav

If you had to show id when redeeming gift cards over a certain amount, merchants could use this to track down "runners". Though I imagine that a lot of them are probably recruited in a similar way to the work from home scams.

The real problem is that merchants are not incentivized to fix the problem as they make money from it.

I worked on a webapp that our team inherited which had 400-800 line controllers (and one that was a little over 1200 lines). When I first started looking at the code I was horrified but then I realized that everything was self contained and due to the linear flow, pretty easy to understand. You just had to get used to scrolling a lot!

The issue that we started having is that pull requests, code reviews, and anything that involved looking at diffs was a lot of work. There were two main issues:

1) Inadvertently creating a giant diff with a minor change that affected indenting, such as adding or removing an `if' statement.

2) Creating diffs that had insufficient context to understand: if your function is large enough, changes can be separated with enough other lines of code to make the diff not be standalone. You end up having to read a lot of unchanged code to understand the significance of the change (it would be an ideal way for a malicious developer to sneak in security problems).

There’s a Nathan Pyle comic with this advice: https://www.slate.com/content/dam/slate/blogs/business_insid...

Living in Vermont for five years taught me that while a 4wd is a better choice for bad conditions, it's because they are less likely to get stuck with spinning wheels, but they don't stop any faster than a 2wd.

I would see way more SUVs in ditches than sedans. People tend to overestimate what their 4wd is going to do for them and aren't sufficiently cautious. The first snow/ice of the year was particularly bad.

All the confusing doors they show are "Norman Doors":

> A so-called “Norman Door” has design elements that give you the wrong usability signals to the point that special signage is needed to clarify how they work. Without signs, a user is left guessing about whether to push or pull, creating needless frustration.

(from the 99% Invisible page)

I often use doors as the introduction to understand affordances. It's crazy that we've had doors for 5000 years and we still make them hard to open.

See "Norman Doors": https://www.youtube.com/watch?v=yY96hTb8WgI

The Design of Everyday Things: https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things

If your app involves a lot of data crunching and that crunching is the bottleneck, then it makes sense to optimize that part.

It's better to have something slow and correct to optimize, so writing it first time round in a slower language isn't a bad thing.

Secondly, shunting work out of your app is easier now than it's ever been. Enqueue and process in a serverless way. Then you can write whatever code that makes most sense for that problem.

> tech stacks are important

I'd argue that tech stacks are unimportant 99% of the time. It really doesn't matter if you use Java or PHP or Python or Node.

Failures that I have seen due to the choice of tech stack include:

- Technologies that your team doesn't know well

- Technologies where hiring is difficult (I've seen attempts to turn C# devs into F# devs and Java devs into Clojure devs and productivity suffered)

- Choosing the flavor of the week, whether that's the hottest Javascript framework or newest NoSQL database

- Over-architecting thinking you were Google-scale with the added complexity hurting velocity (it doesn't matter if you can scale to millions of users if you can't get there)

Generally boring tech stacks work. By the time your Ruby/MySQL monolith has performance issues, hopefully you're successful enough that you can scale out the worst performing parts in some other language/datastore combination. You'll be in a better position to fix performance problems are when you have them rather then when you are trying to predict them up front.

> pedal assist

I can’t wait for pedal assist ebikes to become more affordable. It opens up biking as an option for a lot more journeys, not just for lower-fitness people, but in regions where it’s hilly.

For where I live in Los Angeles, the places I bike to are a couple of miles away (or close enough that walking makes more sense), but uphill all the way. Having pedal assist would mean that I don’t arrive sweaty with tired legs. I don’t need to go 25mph, just 10mph with less effort.

Whether or not you agree with email tracking, the language feels a bit like propaganda:

"YOU'RE PROTECTED. WE BLOCKED A SPY TRACKER IN THIS THREAD"

"A spy tracker" seems a bit dramatic and it's far from a neutral description. What about just:

"This email contained a tracking image allowing the sender to see if you've opened it, we've blocked that for you."

The main use of this feature is to track open rates so that marketers can improve their marketing efforts. Block them if you disagree, but there's no reason to make it sound so nefarious.

Not a dumb question, it does prevent it. However the majority of people enable remote images so distinguishing between images and trackers is useful.

> Self consciousness is an interesting problem. I prefer seeing faces on the screen during the stand-up (such as it is in the days of COVID), but I was told many hesitate to be on camera.

Getting people to turn on their cameras has always seemed to be a challenge in my experience, but it does seem contagious, once a few people do, everyone starts to over time.

It makes a huge difference to see peoples faces over talking into a void. I think empathy is a bit part of it.

> use neutral tools like email

Email might be a neutral tool, but not using a tool like LinkedIn is worse because you're restricting your hiring pool to immediate connections. For all its warts, LinkedIn allows job seekers to connect with a wider range of jobs and job posters to connect to a wider range of potential candidates.

The answer isn't to double down on a "it's not what you know but who you know" world.

Most outside recruiters are terrible, we can agree on that. It's a two-fold problem, they give you poor candidates and harm the reputation of your firm by leaving a poor impression of you to them. I'm looking for work right now and had first hand experience of this recently; I don't know if I should feel sad that I didn't get a job that sounded perfect or happy that I dodged a bullet because if the candidate experience was so bad, what would working there be like?

Most of the issues I have with ambient noise on call could be solved with people investing in a better headset. It's a significant improvement over using your laptop's built in one.

The issue I find a bigger problem is lag causing people to talk over one another. I've been on a lot of calls where the call quality was fine but conversations were difficult because it was hard to judge when the other person had stopped talking.

I think this is important and requires a big shift in how most organizations think of QA.

A lot of QA being done is very mechanical and and done by junior staff offshore to keep the cost as low as possible. This causes the value to be low too, for example, the QA team for a F100 company I worked with would meticulously test against specs and file bugs such as "the error message is misaligned on page XYZ". Which was true, but they missed that the error message didn't make any sense at all.

Improved automated testing has the opportunity to free up people to move from Quality Assurance (preventing defects) to being the voice of the user and ensuring quality products. This shift needs a completely different skill set and mindset, but equally it needs organizations to rethink both the cost of software engineering and the value it creates.

Builds are ways of trying to avoid the audience reading ahead and getting to the conclusion before you've told the story yourself.

For example, if you were explaining your business plan that had three steps:

    Phase 1: Collect underpants
    Phase 2: ?
    Phase 3: Profit

Your audience isn't going to be giving you their full attention while you walk them through Phase 1, because they've trying to understand the whole process think through it themselves.

Instead a build would use animations or duplicated slides to present this flow:

    Phase 1: Collect underpants. (click)
    Phase 2: ?                   (click)
    Phase 3: Profit              

Now you are controlling the visibility of each step. It's very quick to author: create one slide, duplicate it twice, delete content off those two slides.

The slides should be there to reinforce your point. You shouldn't be showing a slide and then reading over the content.

It's one reason that some of my decks have a lot of slides, some may only be shown for 5-15 seconds.

The only two rules that I think matter are:

1) make the presentation interesting to sit through

2) have something that you are convincing the audience to do, you should be telling them to "do X" not just tell them "about X".

Whether you have page numbers (I don't) or builds (I do) or executive summaries (I don't) is not going to meaningfully add to the chances of your presentation landing.

Structure is key. The "Tell ’em what you’re going to tell ’em; then tell ’em; then tell ’em what you told ’em"[1] method works well.

The Duarte Method's[2] "Big Idea"[3] is a good approach:

> A big idea is that one key message you want to communicate. It contains the impetus that compels the audience to set a new course with a new compass heading.

Presentations without a key message are just somebody standing there and talking at you.

[1] https://quoteinvestigator.com/2017/08/15/tell-em/

[2] https://www.amazon.com/gp/product/0470632011

[3] https://www.duarte.com/presentation-ideas/

How I think about a situation like this is that your new manager has given you new information that you need to decide what it means.

Either:

1) You've never been in a safe space with room to fail, you've just been operating under this misunderstanding.

Now you know this, you can correct course and change the goal: instead of trying to deliver the best system possible, your team should focus on delivering the minimum required to meet the goal of having it in 60 days. You can cut scope and reduce quality to meet that goal. They are prioritizing the minimum, not the best long-term option for the company.

You also now know a new fact about the organization: you don't want to be there because it's the type of organization that will change the rules on you and fire you for not meeting (what sounds like) unreasonable goals. You now have a new goal: find a new job. Your manager has helped you re-prioritize, this is priority #1 and your project is relegated to #2. Even if you don't get fired in 60 days, you risk being fired in 65 or 90 days, you don't want to be there one day longer than necessary.

2) You are in a safe space, but your new manager is rogue. Even if this is the case, trying to discover that this is the case, and trying to remedy the situation if it is, has a huge personal risk to you with little benefit.

Your best bet is to look after yourself, not the organization, and start looking for a new job. If you go to upper management and they don't fire him, you're going to have somebody that has power over you that is going to be working against you.

--

It might hard advice to hear, and hard to follow, but you should be less stressed about the situation. You now have a clear understanding of what you need to do.

Sorry for the long-winded reply. My contact details are in my profile, I'm happy to be a confidential sounding board if that helps.

“If there is no solution to the problem then don't waste time worrying about it. If there is a solution to the problem then don't waste time worrying about it.” -- The Dalai Lama

I've spent a lot of my career working to correct projects that have been in a terrible state and had the privilege to mentor and help pull people out of bad situations.

One of the big things I try to do is to get people to think about what they care about and how much they care. Good people do a lot of harm to themselves by caring about the wrong things: they want to be the hero in their story, but forget that six months from now nobody will remember the sacrifices they made.

One part of this is to accept the amount of work that needs to be done is only impacted in a small way by the work you've done today. If you work 8 hours or 16 hours there's still going to be too much work tomorrow.

Working longer hours generally does nothing than hide structural issues. By encouraging teams to cut their workload from 60+ hour weeks to 40, you are forcing these issues into the open.

For those that are ever in a bad situation I'm happy to listen (my contact details are in my profile), sometimes you just need somebody with an external perspective.

SEEKING WORK

Location: Los Angeles, remote for now

I'm an experienced technologist/strategist with 20+ years experience helping (mainly e-commerce) teams and organizations be more effective.

- You need help with your engineering teams? I can help make make them more effective through better tools & processes, I can help with agile coaching, I can help improve your hiring process

- I can help fill gaps, whether that's designing microservices, or security auditing, or integrating systems, or code reviews; or just give you somebody to run ideas by/whiteboard things

- I can help you figure out how to sell more: marketing, customer journey optimization, customer onboarding, overall strategy, improve search, etc.

- I can help you win more deals through better pitches, presentations, storytelling, etc.

- You want to implement a new platform and/or build something from scratch? I can help with vendor/platform selection, architecture, vet potential partners, help with RFPs, audit projects in process, etc.

- If you are a (small/new/growing) professional services/digital agency/consulting organization, I can help you be more effective in sales, delivery, and operations

I work at the intersection of technology, business, and design. I'm passionate and energetic and I've been told that I raise the level of everyone in the room. Please give me a shot.

CONTACT ME: gavin@estey.com

While the idea has some merit in making the cost of repeat offenders expensive so that the force polices itself to protect their pensions, it is unfair to penalize those that have no control including officers that have already retired.

I think the best way forward is to force individual officers to carry liability insurance that covers settlements. This will have the effect of pricing out repeat offenders from the job.

The advantage of being colocated in an office is collaboration--being able to work together in close proximity--and community--adhoc gatherings in communal areas. Take out these things to make the workplace safer and I can't see many advantages of being in the office at all.

I know that there's a lot of people who can't work effectively at home for many reasons, especially city dwellers with tiny apartments, but I wonder if there's a market for small private offices for them. A open office where you sit in a cubicle surrounded by perspex walls seems the worst of all worlds.

When I'm thinking about data stores in large systems I like to break them down depending on how they are used on two main axes: is it fast/slow moving and durability from "we don't care" and "we must never lose data".

It's easier to reason about systems if there's fewer things that require durability guarantees, ideally you want to be able to draw data flows that look like a tree instead of a graph.

I find that Redis fits great because it's perfect for a whole bunch of different temporal shared state needs, everything from sessions to partial results. I've also deployed things like Ehcache, MongoDB, and Memcached to fit these needs and found other tools such as Kafka or RabbitMQ to be great "glue".

Having the root of your important data be something "boring" like Postgres or MySQL (or even Oracle!) is just good risk management to me. I wouldn't want to trust Redis or MongoDB for important data because it adds to the things I have to worry about. It's "keeping your eggs in one basket" while making sure that basket is really well looked after.

I tend to find people who argue with me against MySQL bring up things that haven't been true in a long time such as Unicode or NULL handling.

I'd probably choose Postgres over MySQL for a new project just to have the improved JSON support, but there's upsides to MySQL too:

- Per-thread vs per-process connection handling

- Ease of getting replication running

- Ability to use alternate engines such as MyRocks

If you add the gawkextlib/timex library you can get access to strptime.

https://sourceforge.net/p/gawkextlib/code/ci/master/tree/

Bill Werbeniuk[1] might disagree.

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

Back in the early 00’s I worked for a tiny web design agency that mainly did e-commerce (Yahoo Store, post-Viaweb). As you might imagine the first week or so of January was sleepy, people are coming back to work, sales are low, nobody is going to add new products or want changes for a while.

But, people were very keen on getting their copyright notices updated with the new year. It was a welcome trickle of revenue to spend an hour going in and updating it.

Just about everyone agreed that it was pointless, but they still wanted it done.

There's some non-free options:

Editing/Form Fill/etc: Nitro[1]

Signing: Nitro[1], HelloSign[2], airSlate[3], Smallpdf[4] (limited functionality)

[1] https://www.gonitro.com

[2] https://www.hellosign.com

[3] https://www.airslate.com

[4] https://smallpdf.com

It’s not risk mitigation, more a risk swap between “unknown risk”—we don’t know if this third-party product is going to meet our future needs—and “known risk”—we have full control while we are willing to write checks to fund it.

In the latter case there’s still plenty of risk: you might be spending valuable time building something that doesn’t work, is obsoleted by future change or future products; and the one that most people dismiss, you will be at the mercy of its creators. The people who build your critical technologies will have power over the organization you might regret later, and if they do leave, finding replacements can be hard and/or expensive.

Performance testing is hugely valuable but nothing beats having performance metrics captured and made available from production. You never really know how things are going to perform until you see them under real load against real data.

There’s been many times I’ve been bitten by this, including the one time we found that a small portion of users would set the number of results returned to the max and scroll through hundreds of pages of results, blowing the cache for everyone.

I tend to hear “we run performance tests so we don’t get regressions” a lot more than “we monitor the performance of releases to canaries and rollback”. It shouldn’t be one or the other, both are invaluable.