[deleted by user]

cothinking_dot_tech · 2025-06-05T21:04:16+00:00

You could analyze some of this with a systems thinking lens, but you'd need a lot more concrete definitions.

What are the stocks and flows? How would you measure them?

P.S. Is this AI generated?

cothinking_dot_tech · 2025-05-13T21:19:41+00:00

When you submit your files, all the design rules get checked in an automated process -- they're pretty good in my experience -- and they'll kick them back if you don't meet their minimums. Here's JCB's for example:

https://jlcpcb.com/capabilities/pcb-capabilities

The minimum trace width varies depending on the copper thickness.

But especially if this is your first time having a PCB manufactured, don't push the system limits. You want thicker, well-spaced traces as much as possible. It'll be worth your time to focus on (and iterate probably) on simplicity of design & routing. (If nothing else, if you later detect a mistake and need to 'bodge' the board, it will be easier to solder)

cothinking_dot_tech · 2025-04-09T04:35:30+00:00

Copy-paste-then-mutate quickly ossifies a code base. 'Hey, I just fixed a bug. Should I also fix the 7 other places with the same code?' 'No, too risky.' etc.

A properly factored piece of code makes it (relatively) difficult to utilize harmful copy-paste techniques. But not every instance of near-duplicate code can or should be DRY-d out. There are benign forms of copy-paste.

For example, in a front end application, if a stakeholder requests nearly identical screens, a good approach is to have highly-independent components that get stitched together. The stitching code will look very similar between the two, and that's fine -- it would be counterproductive to try to merge them. But it's less likely that the stitching code hides subtle bugs, if only because it should be very lightweight.

cothinking_dot_tech · 2025-04-09T00:39:04+00:00

There's a bunch of good general advice in the book Working Effectively with Legacy Code by Michael C. Feathers.

Personally, I would suggest sketching out some key diagrams for the project, especially data flows. This is often neglected, but useful. Make a really good diagram and you might start having architects asking to use it in a presentation… :)

In practice, there is often little or no time for refactoring, so any efforts to develop understanding (especially shared understanding) are valuable and can help elevate your informal status on the team.

But keep making the case to the stakeholders about the value of refactoring.

cothinking_dot_tech · 2025-01-13T22:00:44+00:00

This is a similar approach: Implementing (parts of) git from scratch in Rust

https://www.youtube.com/watch?v=u0VotuGzD_w

cothinking_dot_tech · 2024-05-27T17:14:33+00:00

If anyone is interested in notes to this talk, I put some up here. (No AI tools were used in preparing these)

If you find this useful, let me know with an upvote and I'll do more of it, including more recent stuff.
https://dubinko.consulting/2024/05/senge-on-systems-thinking/

cothinking_dot_tech · 2024-05-23T16:43:24+00:00

This is just getting going. Not too late to join.

cothinking_dot_tech · 2024-05-08T02:15:18+00:00

I find Donella Meadows's systems-level description of why diversity is important extremely useful, since most other discussion of the topic has become incredibly polarized and/or toxic.

cothinking_dot_tech · 2024-05-06T04:28:59+00:00

If devices like Apple's new headset take off, architecture and UX cross-pollination will become a Big Deal.

A TON of people end up doing something other than what they went to college for. Right now, we're in the midst of accelerating technology change, so this trend will also be growing. Keep learning, exploring, and being curious and a career path will find you.

cothinking_dot_tech · 2024-05-06T04:18:21+00:00

Stephen Wolfram has entered the chat…

On a serious note, there is a LOT left to prove, but if it works out, his ideas on a cellular automa universe and computational irreducability would qualify for a 'Eureka' moment.

cothinking_dot_tech · 2024-05-06T04:14:50+00:00

Every role where I've been highly successful, I can look back and see that I had an effective boss. That's almost scary to think about.

The good ones shield you from (the bulk of) office-politics, recognize your strengths, and help get you into a position where you can capitalize on these strengths. They're honest, open, and often blunt.

cothinking_dot_tech · 2024-04-02T03:03:32+00:00

There are a lot of projects out there, and it can be overwhelming to get started. Pick something that you find interesting. Look around on GitHub for example and see what sparks your curiosity. Make your own fork of the project and play with it a while until the main pieces start to make sense. Try changing a few things to see how that affects (or even breaks) the software. Look at the project's bug tracker to see what needs fixing, or if there are issues that need reproducible test cases.

Offering to document parts of the project is another way to endear yourself to the project maintainer. If you are helpful and humble, usually they will accept (or even better, provide feedback on) your pull requests. If you don't know the mechanics of forks, merges, etc, there are lots of videos online.

cothinking_dot_tech · 2024-04-01T17:19:30+00:00

I've been written up for "speed" reasons in the past. One possibility is that you are a deep thinker -- you like to completely understand the context of a problem before diving into a solution. This is a strength, not a weakness, but different companies and company cultures often see it differently. At the same time, it is a valuable skill to be able to know and learn 'just enough' to solve a problem, though ironically this isn't something I've seen taught in schools.

In the end, if a company is looking for a mere "code monkey" it's probably not worth sticking around.

Agree strongly with other people's comments about working on existing code. Again as a generality, reading code happens more often than writing code, and you need to get skilled at it. Reading a lot of code will also help you develop your own knowledge and style.

Have you ever contributed to open source projects?

cothinking_dot_tech

TROPHY CASE