Vic González

'Good', I said, 'I've always wanted to be weird in a good way'. 🙃

Estoy descrubriendo formas mejores de ̷d̷e̷s̷a̷r̷r̷o̷l̷l̷a̷r̷ ̷s̷o̷f̷t̷w̷a̷r̷e̷ vivir 🤓📝

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

My measure of productivity is the time it takes to get the solution to a user's problem (their story) into their hands. I couldn't care less about vanity metrics like output volume or token counts. What matters is delivering value sooner. I've found that AI helps with that, but if that's not the case with you, you might want to reconsider how you're using AI.

[Vic González @pikogh]

Cámara @banamex Se te fue a producción un errorsote

[Vic González @pikogh]

@ALEIDAALAVEZ Muy mala tu administración

[Vic González @pikogh]

@ALEIDAALAVEZ ven a arreglar tu desmadre en la Salvado Allende.

[The Superior Man @superior_hombre]

12 Soft Skills that pay you forever.

(Do's, Don'ts & Resources) 🧵

[Vic González @pikogh]

@DES_IPN ¿Dónde podemos comunicarnos para pedir que ayuden la pagina de meterial de apoyo para el examen de admision, por favor?

[Vic González @pikogh]

@Cinepolis @AyudaCinepolis ya lleva varios días que no puedo cargar mi club cinepolis ¿Que se puede hacer por favor?

[Vic González @pikogh]

Todo mal @Cinepolis ¿Cómo porqué quitaste las filas de super fanático en la taquilla?

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

AI-generated code is here to stay, but there are issues.

One thing to consider is the sheer size of AI-generated code. An LLM is not particularly concerned with creating small, elegant solutions. It just puts together things that (mostly) "work" by copying from places like GitHub. That copied code is of unknown quality, and it's pungled together from disparate sources, so it will be unnecessarily large and disorganized. The code usually carries considerable baggage and unneeded cruft.

All of that extra baggage is not harmless. It adds attack vectors, so your code is more vulnerable. It increases load and run times. It makes it harder to find the inevitable bugs and to create real tests. An AI does not understand architecture, so the generated code will never integrate well into your existing system, and the resulting spaghetti can be horrific. Even something as harmless-seeming as pulling in an extensive library so that it can use one small corner of that library increases vulnerability and load time. (It's not as if we would ever do that ourselves 🙄.)

I'm NOT saying "don't use AI." I find it useful, myself. However, I think it's best, given the current state of the technology, to use AI to create small chunks of code that you, as a human, can easily vet, improve, and integrate into the larger system in an architecturally appropriate manner.

Also, it's critical that you fully understand the code that the AI creates. Don't just use it as a black box that "works." For one thing, when (not if) it breaks, you need to be able to fix it. If you don't understand it, that can be impossible.

Finally, it's essential to use tools like strict component architectures that can sandbox the AI-generated code into easily replaceable chunks, ensuring that its problems do not leak out to the system as a whole. No AI on the planet understands architecture—that's your job.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

Demanding a certification in a single development process (such as Scrum) is like demanding that a Michelin 3-star chef be certified in boiling water. No single process is adequate.

The best processes are created by the teams that use them, and they involve elements from "all" of the canned processes and additional elements invented by the teams as well. They are context-dependent and change constantly as we learn.

[Vic González @pikogh]

Todo mal en @Cinepolis Las antenas. ¿Para que dan esas promociones si no las pueden escanear en su Coffee tree?

[Vic González @pikogh]

Ni me quisieron regalar una cajita para Palominas porque "están contadas". Cómo no están contadas sus tapas para refrescos @Cinepolis que mal servicio

[Miguel Ángel Durán @midudev]

Programadores comentando su código

[Vic González @pikogh]

@uber No me deja cancelar viajes la app. Luego me cobrarán si un conductor lo tiene que cancelar. ¿Que puedo hacer?

[Jurgen Appelo @jurgenappelo]

“Just use AI” they said. “It’ll be fine” they said.
Meanwhile, your company culture, ethics, and middle managers are dissolving in real-time.
Here are 22 reasons to panic (strategically).
https://t.co/UkZYebxzFd

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

My general rule is that if there's a certificate in it, it's not Agile. The very notion of a certificate is based on a faulty premise: that Agile is a fixed process, and if you learn and do that process, you will be Agile. That's just wrong. Certificates are nothing more than a grift—a cynical way to separate naive people from their money. Nothing more.

I would feel differently if the certs were offered for free, but there's no Agile standards body for the simple reason that there's no such thing as standard Agile. I also feel differently about someone paying for a good class taught by a reputable trainer that was not positioned as the be-all and end-all of Agile knowledge (though I'm reluctant to endorse any class that teaches a canned in-agile process like SAFe).

Instead, read a few books, watch YouTube videos, take a few good classes offered by reputable trainers, go to conferences, etc.

Of course, in many places, a cert is an "entrance fee" into the job market, so you must get one. It's an artificial barrier to entry that effectively says that you can't be Agile if you don't have the money to pay for it.

[Vic González @pikogh]

@allenholub Is there any good book you recommend to go deeper into this budgeting stuff, please?

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

Budgeting around projects is usually a bad idea. You'll be paying your engineers, even if they're sitting around playing canasta, so why not budget accordingly? Create a budget for the entire engineering department (fully loaded salary * some multiplier for expenses). There. You're done. That was easy.

Now you can assign engineers to (or better yet, let them choose) the work that produces the most value. That is, you plan around value, not around budget. Put people in the place where they'll do the most good. Since "value" changes over time, I'd expect people to move around over time as we reassess where the most value lies. Everything is in slow, yet continuous, flux.

Project-based budgeting does nothing but add considerable complexity to the process. It's a great way to waste money, given that people will finish the project even if it doesn't need finishing or could be scaled way back. We learn as we work. Your budgeting process must take that into consideration.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

One of the most important concepts in Goldratt's "Throughput Accounting" is that inventory (something you've built or spent time on) that has not been released into the customer's hands) is a financial liability. It's money spent with no balancing revenue. Every bit of software that sits idle waiting for someone to work on it is a financial liability—money lost. Opportunity cost is a big part of that. You're paying to write non-revenue-producing software while at the same time losing the money you could have made had it been released earlier—a 2x hit. Of course, delayed feedback ultimately leads to either building the wrong thing or massively expensive rewrites. More money lost. Lots of it. A long backlog that people have put effort into creating and maintaining is inventory—more money lost. Every minute waiting for QA or a DBA decision is money lost. That 10x programmer creating work that's waiting to be handled by the next person in line—money lost. The list is endless. You want to be more profitable? Don't "manage" these delays and dependencies, eliminate them..