It is hard to write software. Many of us write lines of code, and often if we go back, we find flaws and problems in our code. As I look at the solutions others might give for the same problem, I'm sometimes amazed at the way they tackle the problem and what language features they use. I'm especially always intrigued when I see someone using STUFF() or APPLY in their queries. I know I have a bit of a hole here, as I haven't done enough work with them in my career. It's a tool I just don't think to reach for.

Part of that is that I don't know I completely understand how they work in my head, at least not without effort. The lack of familiarity hurts me here, but it's part of the issue that Paul Graham expresses in this essay about holding a program in your head (essay via Brent Ozar).

I certainly have held entire programs in my head, and when I do, I think I work a little more efficiently. Certainly faster, and I can change things as I refine the solution I'm aiming for. I also find that when someone else is touching the code I'm working in, even lightly, it is distracting. The differences in reading my code vs. someone else's are noticeable.

I think this is where working in a team, unless you are pair/mob programming, can be challenging. While discussing issues with others might help find solutions, I do think that groups need to subdivide code into sections and allow each person/pair/mob to work on that code alone for a period of time. Some organizations do this well, but plenty do not.

Perhaps one of the best reasons to be careful about touching the same code in a database is the last writer wins. While some tools might work with the code in memory on your workstation, many of the ways we capture and track T-SQL code come from the database itself. If multiple people change the same object in a shared database, we can easily lose code or frustrate programmers seeing strange behavior.

There are a number of items that Mr. Graham thinks will help programmers write better, or more, code. However, I also think that his problem space is focused more on startups and new applications rather than the legacy code on which many of us work on every day. However, I do take the point that having a more succinct language might allow a programmer to hold more in their head and get more done.

If they're are intimately familiar with the language itself. I think that is a skill managers should promote in teams. And something I need to work on with STUFF and APPLY.