atheken

We used JIRA effectively at my last job, the things that made it work for us:

• stop adding shitloads of required fields. Title, description, branch, priority (defaulted), status (defaulted), type (bug/feature). We might have had some others, but that was all I remember being required.
• stop writing shitty descriptions: spend more time writing something that your co-worker can use. Respect their time enough to try to include enough detail for them to actually use the ticket. Be available to answer questions when they are assigned a ticket you wrote.
• you don’t need extremely granular statuses: the functional role of the assignee is enough to determine what “state” it’s in, trying to codify a unidirectional flow of tickets is maddening and overly complicated. Work is messy, it flows back and forth, you do not need a “rejected by qa” status. Just leave it open and reassign to the developer with a comment. Managers find out when individuals are submitting half-assed work on a regular basis, you don’t need JIRA for that (unless you need metrics to fire them… different problem).

I agree with the premise of the article, JIRA is a communication tool, not a management tool.

Interesting concept, just FYI, there’s a popular code grepping tool called Silver Searcher, and it also uses ag - consider just using august to avoid ambiguity/collisions.

.net has been targeting Linux for like 7 years. There’s open source tooling for it, and you can also buy Rider if you want more comprehensive editor support than vscode (which is quite good and runs everywhere, including the browser).

Java is more complicated, but in either platform, there’s tons of open source frameworks, like log4j that you can pull in without any quality control or direction from “large corporations.”

go was developed by a little company you’ve probably never heard of called “Google,” and they are their first/biggest customer.

rust is interesting, but appears to be governed by a small group of people with some internal drama, and is heavily opinionated to the point that “modern” features won’t be added until they are considered table stakes for any language that hopes to gain traction.

I don’t really understand your argument at all. It seems pretty flimsy.

I use dev containers on Mac, it’s not just about launching services that you need to test your code, it’s about specifying the entire build toolchain to get a deterministic dev environment in an isolated way.

You don’t need to manage the docker containers at all, vscode handles their lifecycle.

You can specify different extensions/configurations per project, so if you bounce between several languages, you’re only using the extensions/configs for a given project.

It also allows for a mostly seamless debugger experience with the browser when you launch a process.

The nice thing is that it sits off to the side, you can use your docker-compose as you normally would, but if you want to provide a full working dev environment for contributors, basically all they need is docker and vscode installed and they can get started.

The devcontainer spec is based on open standards, so it probably will end up in other editors, because it solves a huge problem for teams. The only thing that I think will come close is Nix, but I think it’s limited in scope in some important ways for this use case.

I have no idea what you mean when you say you found an error in the design that says it was an INSERT instead of a SELECT.

If you are relying on a design doc with SQL in it, that’s a massive waste of time.

How many tables are in the schema? Have you reviewed them? Are there any naming conventions being followed, or is everything inconsistently named? Are there specific cases where tables are not normalized properly that you can ask specific questions about why they are that way? If the person that designed the schema is making “trivial” mistakes, there’s no reason to expect that stuff that doesn’t make sense to you will be something they intentionally did.

I guess what I’m saying is, you need to do some due diligence and survey the schema and write down some specific questions and that may lead to writing a UML or other doc to identify errors, but it doesn’t sound like you’ve done that.

You said you were in the role of the “front end dev”. I presumed a structure of an API (usually implemented by a “backend dev”), and a UI (usually implemented by a “front end dev”).

My advice still stands:

You need to clarify the interface where each of your responsibilities are handed off.

If you are implementing the API, you can still produce the same document and then you need to get the other people that need to use it to verify that they can build what they’re doing from that. This means they will need to map the data from the API into the UI elements they need to provide. It also means that someone will need to see how that data will be sourced from the database, and identify anything that is not available in the database.

I understand the predicament you are in, but I don’t know that you’ll get very far with your current approach.

The actual artifact you need from your collaboration is the list of API endpoints and the structure of what the request and response payload will look like for each one. This doesn’t need to be UML, it can literally be a text doc.

By asking for something highly structured that the other people may not know how to make, or do not have the tools to make, you’re putting them in a position where they have to acknowledge that they don’t know how to do something, or causing them to do work that they don’t value. Once you’ve had success on a team and developed trust/respect, you can push for adding process/tooling, but if you’re new to a team, you really have to work with what you’ve got.

Either of you could write a simple doc outlining the API and then collaborate on that (it’s also much easier to actually comment/collaborate on than a diagram, anyway).

I haven’t made a UML diagram in years. Or an ER diagram, for that matter.

Getting a schema dump and/or generating a diagram from an existing system would be useful, it won’t be UML, but can convey similar information. At a certain point, keeping an updated UML diagram is extra work that is almost guaranteed to go out of data instantly.

It really depends on context, but if I’m just talking about estimating something, it’s usually rounding a decimal to a whole number or if it’s already a whole number, rounding it to the closest value that is divisible by 5 or 10.

Other than that, it’s basically just about reducing significant figures to make doing rough estimates more easily.

Fair, I was saying if this was important to you that you might ping them and let them know.

Obvious typos do not contribute much confidence that the author cares at all about quality.

We had about 10-15 lambda “Microservices” each of these packaged up a service/contracts library to be consumed by other services that used them. We also had an MVC API and a few windows services that were built for a “distributed monolith”.

We built all all branches on every push, we tried to deploy updates multiple times a week.

We had 4 devs working on .net

The main thing with sleet is that I made zero effort to prune anything from the feed, so eventually it might cost a few dollars per month for S3 storage, but it was literally zero maintenance after we got it set up.

I’m pretty sure you can delete releases. Probably worth a do-over