Practising Programming (2022)
tratt.net
tratt.net
you aren't forced to use these frameworks and tools. You can chuck a NIH syndrome, and just write everything from scratch.
The only reason you wouldn't is because you aren't interested in programming as a craft in itself, but is only interested in the output and productivity.
- std lib that does some really heavy lifting. (Dep tree is maybe 10 libs total, 2-3 layers deep for mid-sized projects).
- concurrency is simpler and less boilerplate. Data races is a non-issue with good hygiene + race detector
I would normally throw in the Go toolchain as a plus but I think Rusts tooling is very good as well, in some cases maybe even better. It’s much more of a problem with other languages.
if not, then that means those libraries and tools save you less time than it would appear, and you might as well write your own code
Niklaus Wirth said writing an RDBMS was too hard for him.[1] Where does that fit into your "only" reason?
[1] in the Questions/Answers section at the end of this presentation https://www.youtube.com/watch?v=EXY78gPMvl0
You can also just choose one language/tool/framework and do _everything_ in it. I know this might get snubbed, but you can do almost anything these days with TypeScript. It can be as typed or dynamic as you want it (well sort of), plays well with UI/web/react, server with node, has pretty good performance these days, and you can even easily run CLI scripts with tsx. `#!/usr/bin/env tsx` (https://github.com/privatenumber/tsx)
The thing is, you don't! Nowadays you don't even have to go out and buy Turbo Pascal in order to practice, you can just create an HTML file on your desktop and open it in your favorite web browser! Heck, if creating a file is too complicated you can press F12 and start scripting right away. Most operating systems come with Python preinstalled, so you can just drop into a REPL at any time, or write a script and run it.
Programming hasn't become more complicated to get into, it's just that software engineering is growing up and people are given the false impression that they need to start with the professional tooling. We in the industry should be reminding people how truly simple it is to get started with something small, not bemoaning the existence of the large, complex and nearly interchangeable tools that we have to choose between to work at scale.
By filtering out the noise and starting out small and simple, we'll make it much easier for newcomers to grasp the basics before learning about modern toolchains.
Now you need to fool non-technical people into demonstrating "industry" knowledge of a specific combination of Tool A/B/C.
You're right, though some people want to learn to program to either have fun, or to make simple tools for themselves (see e.g. the discussion here: https://news.ycombinator.com/item?id=38877423; disclaimer: I only read a small fragment, but it seemed very interesting)
I get your point, but I think it's a bit of a myth. I work on mainframe applications and when you look at the actual business logic, there is a comparable amount of it in the apps that are 20, 30, 40 years old. I would even say that the modern methods of building software are to the detriment because there is a lot of incidental complexity coming from the tooling.
It seems that creation and maintenance of business logic for a given domain isn't really much helped with modern tooling, so it takes about the same time to develop. On the other hand, businesses today are demanding things to be done cheaper with more UX polish. This means that actual software capabilities (which require domain knowledge) are made less general and take more time to develop. I would say today, many applications are simpler in terms of features than 20 years ago.
Dismissing that engineering because your mainframe applications do more "work" with less code is shortsighted, a continuation of the "frontend developers aren't real engineers" meme that has finally started to die.
If all your customers care about is that the paperwork crunching and adding up the numbers gets done right and on time every day (and after that, as cheaply as possible) then it's actively counterproductive to spend resources on a nice frontend.
I don't think anybody is implying that there is no market for frontend engineering, just that resources spent on frontend are necessarily resources not spent elsewhere, and that different teams naturally have different priorities.
I'll illustrate what I mean by less features on desktop application. 30 years ago, there was a text editor called Ami Pro. You as a user were completely free to redefine its UI. You could also define keyboard shortcuts.
Today, people use, say, Google Docs which doesn't have these features. Users are supposed to use common UX, designed by experts. But which one had better UX, really?
I mean it's easy to say that medieval people built huts and now we build skyscrapers, and so the technology brought undeniable progress. But they also built cathedrals (note I am NOT using "cathedral" here in contrast with "bazaar"). Skyscraper building techniques don't really help you build cathedrals faster, because one of the attraction of the cathedral is that each of them is heavily customized and unique. The problem is, since it's easier to build skyscrapers with the same amount of material, nobody wants to build a cathedral anymore. And it's perhaps a loss.
I was pointing out the cathedrals of software do exist, built with perhaps cruder tools, but more actual business logic and features. So in some strange way, having more productive tools to build applications also boxed our thinking into how things should be done, and I don't think it has to be that way.
(Another perspective is that a medieval church used to be a sort of communal project more than a skyscraper is today. Commercial software used to be lot more moddable 20 or 40 years ago than it is today - MVS is a nice example. And out of these modding capabilities many features have been built - often by users - that would never make business sense today.)
i am rather in the desert, where there is nothing and the few bugs you encounter are avoidable, but super fatal at the same time when not avoides or handled with care :')
- k8s
- ci/cd
- containers
- gradle/npm/poetry/composer/etc
- ORMs
- aws/gcp
- jira/scrum
- swagger/grpc
- kafka/sns/rabbitmq
and tons of yaml.
It certainly seems to help me to be very productive. I am not as advanced as Swift scientists and academicians, but I speak it without an accent.
As far as automating everything; I automate some stuff, but not that much. If the act of doing the automation teaches me something, I guess that's good.
However, automation often encourages a "Greatest Common Denominator" approach to things that may be best served as hand-crafted, artisanal work. An example is what I'm working on, right now. I'm preparing an app for App Store release, so I have to do a whole bunch of screengrabs and videos. It's a big fat pain. Many shops automate this.
But I am also carefully choreographing the process, and ensuring the best Quality for everything. The App Store page is incredibly important to branding (something many techs don't take as seriously as they should, IMNSHO). It's worth it to spend as much time as possible, working on it. I only do this, every now and then, so it's not really a big deal.
Getting in the habit of automating stuff in your editor and environment can also have a real snowballing effect. Yes, you end up “wasting” some time with yak shaves that don’t work out. But it doesn’t take long before the scope of what you can tackle in a day grows. It’s really profound how much friction you can remove, and how much friction there is in fresh environments.
Also, and ymmv, but a lot of repetitive tasks can be pretty soul crushing. Too much toil and you can come to dread your job. Automating something away almost always feels rewarding to me. Keeping yourself happy and motivated in your work should also count for something.
At my current job we have some code that generates typescript RPC bindings from our java code. It's quite slick but the backend definitions and the frontend definitions aren't linked, and navigation between them is a pain. So I decided to write an IntelliJ plugin that allows for navigation and find usages across our two languages. Took 2 days-ish, but totally worth it.
There's another benefit, too. By "living in the system" and treating every part of the computer as something to manipulate, automate, and control, you get a more organic sense of the shape of the thing. It's a fairly common occurrence that I'll have a feeling that something ought to be different without really knowing why, and then later that feeling is proven out (this typically has to do with stuff like the shape of dependencies or the usage of tools in contexts that are a misfit, which then turns into ever-expanding kluges that should have been better design from the outset).
That said, try explaining to someone else on the team that "I dunno, just doesn't feel, like, nice".
The two main ones are: data structures and algorithms and rapid prototyping.
The former is basically leetcode stuff and straight forward. I want to be able to implement bread-first search without having to look it up. And I want to be able to do it without it occupying too much space in my mind. Repeated practice helps me retain this kind of stuff so that it becomes reflexive and almost like muscle memory.
The other kind of practice takes a bit more work. I did this for a period where I produced a body of small prototype games. The idea was to write them in the fastest way I could. I forgot all about coding practices that you would use in production code and went all in on, “how fast can I get from typing the first byte of source code to user interaction?”
For these projects I used a timer. Everything was permissible. It was code I wouldn’t use again so I didn’t care about it being reusable or readable or anything like that. I kept light notes on my experiences with each of them.
Prototyping is an oft-overlooked skill that can some times be useful. The idea is to write some code to hash out the idea; experiment with it in the fastest way possible with the goal of finding out whether the idea itself is viable. For a mountain of a task like developing a game, and in boring stuff like enterprise software, it’s useful to save yourself a bit of work from going down a dead end if you can scout ahead a little bit.
Something I've found tough at this point in my career 10 years in is trying to practice skills that I don't care as much about but can be necessary at times. I have many friends in my area that are very skilled at frontend development. I am not. I will reach for the first template library I can find to get a frontend built. I wish that I could take the time to properly sit down and learn HTML/CSS/JS but every time I do I get some weird focus block. It's almost as if my brain shuts down and refuses to take that information in. Maybe because I know that my time is limited?
I have to set really strict schedules with myself to get any kind of practice in. Sometimes this works and sometimes it doesn't. Oh well.
I'd love to start automating more common tasks for myself.
The fun thing about programming tasks and tools in particular though is that you crystalize your mental models into tools because of the natural of computers.
The "busy" developers never or hardly see that problem, because they're happy with their business already !
Both lead to learning to program I suppose. But the former is an alien concept to me. The latter is the more natural.