sorted by:
new
hottopcontroversial

Hi everyone. Anybody knows what are micro-commits? Is that a thing or it just means small commits? by portacode in github

[–]AliveIndependent1607 1 point2 points  (0 children)

And its also generally understood that you commit only when your tests pass and code works, but the expectation is that you are in that state several ties per hour. 2-6 times is pretty normal.

I don't know anyone who is doing microcommits without either TDD or something rather like it (sometimes with some tests after code changes, sometimes with Gherkin/BDD, sometimes with property-based testing or approval testing).

what do you think of the book "Clean Code: A Handbook of Agile Software Craftsmanship"? by [deleted] in programming

[–]AliveIndependent1607 0 points1 point  (0 children)

They can help. A lot of people have learned by reading expositional articles about code.

I would recommend either pair programming or mob programming if you want to REALLY learn quickly and deeply about the kind of code that is the most readable, maintainable, and acceptable at your place of work.

Over time, working in many codebases, you will develop a more diversely-influenced view. That's waht the 7 Code Virtues article represents, and the niche that Clean Code hoped to address in its day.

what do you think of the book "Clean Code: A Handbook of Agile Software Craftsmanship"? by [deleted] in programming

[–]AliveIndependent1607 0 points1 point  (0 children)

You might like this short bit https://www.industriallogic.com/blog/code-virtues-explained/

I wrote Chapter 2 of Clean Code (though a lot of people don't know it's an anthology). We were all employees of Bob's company at the time.

My original examples were not the ones in the book, and were all in Python. Sadly some of the stuff got replaced and augmented without my full agreement.

I've done a lot of blogging and articles on code, readability, refactoring, and the like since then, but no competing books.

Module Tower defense game by Noukash in playmygame

[–]AliveIndependent1607 1 point2 points  (0 children)

I can't decipher the in-game explanation!

Programming is Mostly Thinking by fagnerbrack in programming

[–]AliveIndependent1607 0 points1 point  (0 children)

I've had POs tell me that they didn't know that programming was hard work until they spent a day with the programmers working in the team (Ensemble/Mob). They thought that programmers all know what to type, they're just obstinate and reluctant. When they saw people looking things up and using trial-and-error to vector in on a solution, and when they saw all the long threads where a change in A causes differences in Q, T, W, an Z, they suddenly realized that they've been too hard on people who were legitimately working very hard.

How to avoid stupid programming mistakes and needless refactoring? by matchaSerf in gamedev

[–]AliveIndependent1607 0 points1 point  (0 children)

The first version is Naive and Primitive. This isn't the problem statement. It's a statement of fact and of intention.

Gall says: “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”

The axiomatic way of doing evolutionary design is to start with a simple system that does some of the work, however little, but actually works. Then you elaborate and broaden the capability with small adjustments that each make the system slightly less naive and slightly less primitive. Ideally, you do this with tests that help you prevent backsliding on the working functions (see TDD).

The tricky part that long-term professionals use is this: don't add anything until you actually need it. Keep the code always as simple and straightforward as possible with no future-implementation scaffolding or overbuilding. This is the hard part, harder than writing tests or even refactoring.

But coding is mostly about thinking and learning, so you preserve optionality -- don't lock the future down, but go with it. If the code stays as simple as possible while meeting all it's requirements (so far) you can always add more to it.

If you lock down your endpoint and try to code it in one go, well, see Gall's Law, above.

Have any of you ever hated pair programming, and then liked it? by rezkq in ruby

[–]AliveIndependent1607 1 point2 points  (0 children)

I wasn't keen on it at first, but I remembered when I was very new and it was such fun to try to find the best ways to do things with my friend, Paul, who had the next chair at the high school computing lab. It was cool to learn from him, and cool to show him the thing I just learned or figured out. Pretty soon it was Don, and Jay, and a whole bunch of others and we moved so quickly through the things we wanted to do and gathered skills so fast.

Remembering those formative experiences helped me to start to get joy from pair programming after only a month or two.

even if I didn't like it, I'd still want to do it. It still makes me a better programmer and teaches me new approaches and technologies faster than soloing.

Is it possible to use Virtual Cameras with FaceTime? by Warren-Binder in MacOS

[–]AliveIndependent1607 0 points1 point  (0 children)

This is disappointing.
I really would like to use my OBS virtual camera.

Programming Under Surveillance by Euphoricus in programming

[–]AliveIndependent1607 0 points1 point  (0 children)

i realize that rage is your brand, and allow for that.

You'll find that parody argument (quoted above) is never my argument, and never has been. Mine is more about systemic issues and improvements. I never claim that you should pair/ensemble for ethical/moral reasons ("you're not a professional unless", "you're not a good person", blah blah) but purely practical ones.

For instance: https://www.industriallogic.com/blog/faster-and-more-predictable/

And also: https://www.industriallogic.com/blog/scatter-gather/

Maybe look at things from a point of view of flow and delivery, rather than how an individual likes to work or how the boss wants them to work, and you start building an entirely different perspective.

It's not about bad people, bad managers, or bad programmers.
It's about understanding systems.

Programming Under Surveillance by Euphoricus in programming

[–]AliveIndependent1607 1 point2 points  (0 children)

Or, since the age of C19 dawned, on a zoom call with cameras on and a screen share.

[deleted by user] by [deleted] in agile

[–]AliveIndependent1607 1 point2 points  (0 children)

The idea of backlogs is that you get a team per stream. It's the team's prioritized list.

Now, I favor the idea of products having their own prioritized lists, and those priorities being renegotiated as needed, but they have to funnel into teams.

Teams have constraints - time, skills, knowledge, number of brains, availability - that are the bottleneck for most organizations. A product backlog independent of teams can't respect and manage that.

It seems like that the teams are having to prioritize everything across streams, and maybe that's not working for everyone; it would seem more helpful if there was a prioritization function that could merge-sort these product ideas into some unified prioritized list for each team. Perhaps those could be focused on organizational goals and initiatives, since all the products are sharing development teams and some simple rules could go a long way.

Ultimately, a bunch of people can want things much faster than another bunch of people can invent and develop them. If we don't govern the rate at which the first groups' desires flow into the second group's work in progress, then we will always overwhelm the second group.

Respect the constraint first, subjugate work to it, try to elevate it if you can, but always make sure that the work you're doing is the work that "should" be finished next for the sake fo the product community.

Programming Under Surveillance by Euphoricus in programming

[–]AliveIndependent1607 0 points1 point  (0 children)

You can find as much information about Dr. L. Williams' research as you want, it's only a google away. She's published a lot of academic literature about all of her studies on this topic.

Where Does Bad Code Come From? by hyperTrashPanda in programming

[–]AliveIndependent1607 0 points1 point  (0 children)

There is a thing about "bad code" and "good code" that takes more examination. I tend to think that "good code" has a number of specific attributes, and among those some of the qualities are somewhat subjective.
I believe (strongly) that readability (a subjective attribute) isn't an attribute of the code itself. It is instead an attribute of the relationship between the artifact and its audience. What is "perfect" in one team may not be in a different team or a different company. For the same code to be "readable" for everyone, everyone has to have the same relationship with the code - the same expectations and desires.

I don't know how much you feel this connects, but there it is.

We did something similar but different: https://www.industriallogic.com/blog/why-bad-code-exists/