> We don't like writing code on the whiteboard, we don't like mind teasers, we don't like programming puzzles, and so on.
I love all of those things. In fact, dare I say I like them more than the job itself:
(0) The given task is usually short, self-contained, and has a single best solution that can be found purely by logical reasoning.
(1) There are no requirements of the form “you have to use this obviously misdesigned technology”. All one has to do is come up with data structures and algorithms.
(2) I won't piss anyone off for trying to do things in the most elegant way possible.
At least 80% of programming is menial. At least. The interesting bit where you understand the problem and find the best solution virtually always takes far less time than actually banging through the code. nevermind documenting it, testing it, etc. The hardest part is simply not screwing up.
I feel blessed if 5% of my day involves actual critical thinking.
>>Meanwhile, my friend wrote his code only after thoroughly understanding the problem. He used almost all the allotted time to think about the problem. He did not write code until minutes before the deadline.
I fully appreciate this. Indeed, coming up with good idea of exactly what the problem is and then getting an idea of a computational solution are the most crucial steps to programming. Once you get a fairly clear picture of a computational solution, you can very easily write the code.
But coding is what must be done ultimately. If you do not write code that can be executed on an electronic (till now) computer, you haven't actually solved the problem, period. No amount of hand waving can do away the coding. I think, a child who learns to code can get many cognitive benefits out of it.
Of course, jumping right into coding without giving a thought as to what the problem is is a sure-shot way to frustration and other ill-effects. It's like getting a soldering gun and trying to build a complex circuit without doing any analysis and design first.
> I think programming is easy. When I sit down to code something, it feels deterministic, and everything falls into place
this is something i've always felt and was always confused by when I saw others coding. Nothing was ever "hard," coding just made sense to me. So logical, so easy to do, concepts may be difficult to grasp at first, but it never took long to grasp and commit it to memory.
It is highly stimulating intellectual effort though. Sometimes I sit down and spend hours just thinking about the best way to do something. It's some kind of philosophy: the abstractions we create reflect the way we understand things. To write good code, we must study the computer science and the problem domain itself.
Without this, it's just boring mechanical work. Once the project has been figured out it ceases to be interesting. Some of my projects are unfinished because I can't justify spending more time on them even though I know exactly what must be done.
> You know what I really wish? Programmers would spend 1/100th of that algorithm studying on learning to write readable, maintainable code.
IME, programmers that write readable, maintanable code and those that have a solid grasp of algorithms and theory as it applicable to the problem domain tend to overlap considerably. Having a clear analytical mental model of the approach to the solution leads to clearer and cleaner code -- and, where necessary, clearer and more useful comments -- than hacking your way to something that works. (And I'd say thats as true of my own code -- where I've done work on both extremes of the clear model to hacking-my-way-through axis -- as of others' code I've seen.)
> In particular, develop the ability to enforce encapsulation on your mental model of the program you are working on, so you don't need to keep the entire thing in your head all the time
This one is hard, because the company will push you to make the model as complex as your brain can bear, and all of our programming tools are designed to support the most complex program the toolmaker could imagine. And on your resume you want to put the most complex set of capabilities that you could possibly put. And in your mind you want to be the most dangerous programmer you could possibly be.
It took me 20 years to realize that there are ~0 problems that necessitate more than an intro-to-programming level of tooling.
It took that long because the whole ecosystem around me pushed me away from transparent coding towards grandiose coding.
Even now, I can rarely write simple code for hire because my coworkers have installed a veritable AGI of declarative tooling, and not using it is more conspicuous than using it.
But I try. You are absolutely right plain (not fancy) code is the ultimate goal.
Programming is the exact same way. If ever I'm in doubt of someone's design and I have an inkling of respect for them, I'll try to design the code from scratch in my head, or sometimes even redesign a toy version myself. This usually surfaces some weird property of the problem that explains their code. You can also go through their thought processes and see exactly how they made decisions along the way. I'd argue you can even infer philosophical viewpoints in some cases, too - all without actually communicating with the author.
I love that about humans. One of the things I really admire about us.
> If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
OMG, this is so so true! I have seen people writing complicated/fancy algorithms to do simple stuff, and 2 years later they don't even know how did they do it!
> When it comes to writing code, the number one most important skill is how to keep a tangle of features from collapsing under the weight of its own complexity. I've worked on large telecommunications systems, console games, blogging software, a bunch of personal tools, and very rarely is there some tricky data structure or algorithm that casts a looming shadow over everything else.
Could not agree more. Most programs require appropriate organization. The Venn diagram intersection between puzzle solvers and organizers is pretty small. The last thing an organizer wants to see in the code is unneeded cleverness. That is, cleverness that is only there because the author is a bored puzzle solver.
> Now, programming feels a lot like woodworking: a deliberately inefficient way to do something, just because it's fun.
Now that is a standout line right there. It perfectly describes some of my own personal projects. Sometimes—oftentimes—they go nowhere but I had fun.
One such task was developing a secret Santa system in python with an auto mailer and “paper” backup while in Hawaii last year. It took me part of a morning during breakfast before we went out for the day. I refined it when we got home. There were others already out there and it did nothing more then putting names in a hat, but it was fun. And it’s reusable. And it had the added benefit of needing no moderator—nobody in on the secret.
The metaphor of a wood working project just seems to fit so well. Nice one.
> Programming shouldn't be (just) thought of as engineering, but also as simply giving the computer complex instructions.
I really like this phrasing. I'm not really an engineer. My code is mostly rough, but it is functional and does what I need it to. I don't program to build a skyscraper, I program so my computer can do a thing I need it to do.
> With programming you have source control and some form of an undo command. You also have a compiler and (if you can be bothered writing them) tests.
There is always an undo, just get another board.
> Building software is like taking all the fun parts of DIY and leaving all the boring / dangerous / physically taxing parts behind, and you can pretty much do it wherever you have a power supply and internet connection. That's why I first loved it and why I continue to do it today.
I have a different point of view. The software you build is ephemeral. You can't show it to someone. The architecture and the beautify of it's interplay is hidden and it's art is only available to you. I can show you my dovetail and let you feel how smooth the finish is. It's real. You can explorer it with your senses.
> The bottleneck has always been in understanding all the implicit assumptions baked into the system that for one reason or another are essential to its correctness.
> It takes a particular kind of masochist to enjoy reverse engineering a black box from just poking at it with simple linear impulses.
These are great observations and brilliantly put. In particular the second one I think rightly explains why some very smart people definitely do not take to programming as a profession.
> I must admit, the _art_ of writing readable code really appeals to me and is one of my finest joys in programming
One of the best compliments I've ever received was when a team member told me I created the most beautiful looking code she's ever seen. This was from both a pleasing to the eye and ability to grok perspective. The latter was mostly due to naming things in ways that made their purpose obvious and avoiding the temptation to do as much work in a single line of code as possible.
I love all of those things. In fact, dare I say I like them more than the job itself:
(0) The given task is usually short, self-contained, and has a single best solution that can be found purely by logical reasoning.
(1) There are no requirements of the form “you have to use this obviously misdesigned technology”. All one has to do is come up with data structures and algorithms.
(2) I won't piss anyone off for trying to do things in the most elegant way possible.
What's not to love?
reply