135 karma · joined March 14, 2012
I don't get the passkey hate -- moving to public key challenge for authentication is a strong step forward for web security. Each browser / OS safeguards & backs up the private key (and even if that's lost, you can still reset your auth credentials using a normal "forgot password" flow).
- Transparency about the work. (Communicate progress without being prompted. Share screenshots & be excited about what you develop!)
- Don't be a hero. (If something is difficult, collaborate with the team and don't go it alone.)
- Be minimal. (Development is an additive process, and it's easy to "chrome plate" a development story. Be minimal and discuss above & beyond opportunities with the team before working on them [or just create a ticket for later discussion].)
- Don't compromise quality. (It's easy to want to skip tests or refactor later, but that carries invisible costs & churn during PRs.)
- Refactor as you go, but don't over do it. (Nobody likes a 1000 line PR. A major refactor means large code change [risk], large review, churn on correcting the PR, long time before feature is merged, ...)
- Solicit feedback when you do want to cut corners. (Explain what the cost is in a quick implementation and why it's a good idea to implement minimally at this phase. Identify ways to mitigate risk / make refactor simple later.)
- Don't overwork. (Developers tend to work harder in off hours and burn themselves out. What they don't realize is that their total contributions to the team go down significantly when they overwork.)
- Be honest. (In a team development setting, some folks will communicate that they're further along on a story than they actually are, with the intention of making up the development effort. This causes overwork -- and the rest of the team can pick up on the dishonesty. I would rather have a member of my team say that they're having an issue with solving a problem [or there are external life factors] than feeling like they have to go it alone.)
- Ask for what you need. (Organizations can easily pull developers into meetings and monopolize their time. Push back and ask for focus blocks.)
- Be candid in retrospectives. (It's the one venue where management is literally asking you what could be better. So many times, people are waiting for someone else to speak before they voice their opinions. Have a conversation with a team member before retro to validate your opinions if you are self-conscious about them.)
- Be candid in 1:1s with your management. (Typical management will lose the developer perspective and rely on feedback to be able to adjust team policies. If there's no feedback, then problems fester.)
--
I get that this list leans on being extroverted -- and that some folks are introverted. It's totally a vulnerable position to put your hard work / opinions out in front of a team for review. It's even more intimidating (impostor syndrome) when you're working with really smart people.
A good manager will mentor their staff on how to follow through on these expectations, and will also actively work to make the team environment a safe space for constructive conversation.
There's a lot more micro nuance depending on the team and business environment, but generally, I believe this is a good starting point.
Then, in the same context, you correct it by providing it with more information about how you like to structure the tests. It starts to understand the "style".
Then, you start to provide the context with testing concerns. By the end of it, the AI context is pretty good (80-90'ish%).
It's nice, as a developer, to be able to say: "test that asset is deleted when DELETE /asset/:id", and the AI converts that into a proper test case, using familiar variables / test structure / corrects the abbreviated text into a proper test title, etc..
I don't think this behavior is customizable.. (but maybe with some hacking).
It's important to understand when the business needs a certain capability, and that should be communicated to the development team (so that the correct scope tradeoffs can be made). Bonus points if the business can communicate the challenge they're trying to solve as opposed to the desired output. (Sometimes, you can start with a simple shell script that relieves the pressures of the business while iterating towards a more feature-rich solution.)
It's also important for the business to understand that the goal is a minimum functional implementation for the capability, and that there are development quality standards that must not be sacrificed to hit a date (bad code is a liability). Also, they have to understand that the date they are communicating to the development team is a "I would like it by this date", not a deadline / guarantee that they'll have that software capability on that date. (As a consumer, I do not set deadlines on a provider in many industries.)
Finally, a manager needs to understand the project health on a regular interval and communicate progress and confidence levels as the project continues. This is usually where expectation management goes wrong -- because the conversation about the work becomes metrics driven (instead of talking about the true story of what is actually happening with the work).
Everyone involved needs to understand the flexibility required to develop a useful, trustworthy product -- and that the time required will vary depending on a number of factors (some knowable / mostly unknowable).
As long as there is trust and expectation management between all stakeholders, a program will usually go positively (and relatively stress free).
(Lessons learned from shipping enterprise software applications & running a development consultancy.)
I use Twitter for tech, but my feed is now conservative politics, gore video, & tech tweets intermingled.
When I was thinking about rolling my own federated social service (during the whole Twitter / Mastodon shuffle), I started thinking about the negative impacts of federation. “How can I build a kill switch into this thing in case bad actors start to participate?”
Of course, that means a central authority having moderation control.
But then, part of me thought.. does there need to be a kill switch? Do we want centralized moderation control? If laws are being broken, or social issues are being pressed to the fringe (*lons X), then the ISP would intervene. Or… the responsibility of moderation shifts elsewhere than the provider of the software. (To where do moderation responsibilities shift, if anywhere? I think is still a question.)
I personally landed at the spot of: it’s really no different than what the WWW provides — it’s just easier access. But, is that easier access to self host content and media dangerous? (lol I guess I’m still conflicted about what could happen with wider ease-of-access to self hosting.)
… back to sleep. This stuff literally keeps me up at night lol
(I didn’t get to the other comments further down in this post that talk about content moderation .. but I’m seeing them now!)
Also, services like Twitter started off with a developer friendly open API, and then it got closed off when the business needed to make money off the platform. What's the difference with Bluesky?
At runtime, it’s functionally close(ish) to malloc/free and doesn’t carry much overhead.
The things I like about flight simulator:
- it’s great for checking out an unfamiliar area you’re flying to
- you can connect ForeFlight to it, so you can use your digital charts / EFB in the same way you would in the cockpit
- you can get really good IFR approach practice in
- with head tracking (or vr), VFR flight is pretty accurate to the real thing
Pot is very nice for managing the jails — but I didn’t see anything that behaves similar to docker images as part of its feature set?
The jails system + zfs is pretty nice. If there was an ability to snapshot a jail and easily package it as an image… I wouldn’t look back at docker again.
The commercial line still uses metal gears. The maintenance on it is to check grease/lubricant after a certain amount of use.
(We used the stand mixer daily. Our home edition lasted 6-9 months before needing a gear change. The commercial edition has been going strong for a few years now.)
I’m sure there’s a reason why they moved to a fail-safe gear for consumer use — but as a consumer — I have no clue what that reason is. (We do ask a lot of our mixer tho!)
Tearing a system down and replacing it has a significantly higher cost.
I’m about to leave my job to work on a fashion startup with my husband. There are some technical aspects to the business that I am building into products, but my immediate focus is to get his clothing store online.
I know the product(s) I want to build will be compelling, but my concern is not having enough cash to hire a small team.
At what point is it best to apply? After you have a working application environment? After you have 1-2 people on your team?
Thats all I got to the story. Didn’t participate in the lawsuit .
This is important, because a company can be held liable for wrongful termination. [2]
[1] https://www.nolo.com/legal-encyclopedia/making-layoff-decisi...
[2] https://www.employmentlawfirms.com/resources/employment/wron...
Sure, there are a few enhancements that can be made (state management), but this is a great starting point. Nice job!
Thanks for sharing.