Live data from Hacker News

Programming Is Mostly Thinking (2014)

agileotter.blogspot.com

321–330 of 339 posts

Re: Programming Is Mostly Thinking (2014)

#321
post #101

Great article. I just want to comment on this quote from the article: "Really good developers do 90% or more of the work before they ever touch the keyboard;" While that may be true sometimes, I think that ignores the fact that most people can't keep a whole lot of constraints and concepts in their head at the same time. So the amount of pure thinking you can do without writing anything at all is extremely limited. M…

> writing code should be actually seen as part of the "thinking process" I agree. This is how I work as well. I start coding as quickly as possible, and I fully plan on throwing away my first draft and starting again. I do a fair bit of thinking beforehand, of course, but I also want to get the hidden "gotchas" brought to light as quickly as possible, and often the fastest way is to just start writing the code.

I don't get great results myself from diving into coding immediately. I personally get better results if I have some storyboards, workflows, ins/outs, etc. identified and worked-over first.

But when I do get down to writing code, it very much takes an evolutionary path. Typically the first thing I start writing is bloated, inefficient, or otherwise suboptimal in a variety of ways. Mostly it's to get the relationships between concepts established and start modeling the process.

Once I have something that starts looking like it'll work, then I sort of take the sculptor's approach and start taking away everything that isn't the program I want.

So yeah, a fair amount of planning, but the first draft of anything I write, really, code or otherwise, is something for me, myself, to respond to. Then I keep working it over until it wouldn't annoy me if I was someone else picking it up cold.

Re: Programming Is Mostly Thinking (2014)

#322
post #309

Earlier quoted context omitted.

I see "code that looks the same" being treated as "code that means the same" resulting in problems much more often than "code that means the same" being duplicated.

can you clarify your comment with some examples, because i'm not sure what you mean, even whether you intend to disagree with the parent comment or agree with it

Lets take pending orders and paid for orders as an example.

For both, there is a function to remove an order-line that looks the same. Many people would be tempted at that point, to abstract over pending and paid orders to have both reference the same function, via adding a base class of order, for example, because the code looks the same.

But for a pending order, it means removing an item from the basket, while for the paid for order, it means removing an item due to unavailability. So the code means different things.

Lets then take the system to have evolved further, where now on the paid for order some additional logic should be kicked off when an item is removed. If both pending and paid for orders reference the same function, you have to add conditionals or something, while if each has its own, they can evolve independantly.

And it definitely is disagreement with the parent comment. Sorry to have not elaborated on it in the first place.

Re: Programming Is Mostly Thinking (2014)

#323

Earlier quoted context omitted.

I had the same thought as I read that line. I think he's actually describing Linus Torvalds there, who, legend has it, thought about Git for a month or so and when he was done thinking, he got to work coding and in six days delivered the finished product. And then, on the seventh day he rested. But for the rest of us (especially myself), it seems to be more like an interplay between thinking of what to write, writing…

> I think he's actually describing Linus Torvalds there, who, legend has it, thought about Git for a month or so and when he was done thinking, he got to work coding and in six days delivered the finished product. And then, on the seventh day he rested. That sounds a bit weird. As I remember, linux developers were using semi-closed system called BitLocker (or something like that) for many years. For some reason the o…

Well, if you want to take what I said literally, it seems I need to explain..

My point is, he thought about it for some time before he was free to start the work, then he laid down the basics in less than a week, so he was able to start using Git to build Git, polished it for a while and then turned it over.

Here's an interview with the man himself telling the story 10 years later, a very interesting read:

https://www.linuxfoundation.org/blog/blog/10-years-of-git-an...

https://en.wikipedia.org/wiki/Git#History

Re: Programming Is Mostly Thinking (2014)

#324

“Programming is mostly thinking” is one of these things we tell ourselves like it is some deep truth but it’s the most unproductive of observations. Programming is thinking in the same exact way all knowledge work is thinking: - Design in all it’s forms is mostly thinking - Accounting is mostly thinking - Management in general is mostly thinking The meaningful difference is not the thinking, it’s what are you thinkin…

The article isn't for programmers, it's for non-programmers (like management) who think it is mostly typing, and describing what's going on when we're not typing.

Re: Programming Is Mostly Thinking (2014)

#325
post #87

Earlier quoted context omitted.

I don’t really know what “think algorithmically means,” but what I’d like to see as a lead engineer is for my seniors to think in terms of maintenance above all else. Nothing clever, nothing coupled, nothing DRY. It should be as dumb and durable as an AK47.

> Nothing clever, nothing coupled Yes, simple is good. Simple is not always easy though. A good goal to strive for nevertheless. > nothing DRY That's interesting. Would you prefer all the code to be repeated in multiple places?

The problem is that most developers don't not actually understand DRY. They see a few lines repeated a few times in different functions and create a mess of abstraction just to remove the repeated code. Eventually more conditions are added to the abstracted functions to handle more cases, and the complexity increases, all to avoid having to look at a couple lines of repeated code. This is not what DRY is about.

Re: Programming Is Mostly Thinking (2014)

#326
In my experience, of some decades, with programming of wide variety, in recent decades

"Programming Is Mostly"

(1) making sense out of missing or, as technical writing, badly written documentation

needed to do the

(2) mud wrestling of system management.

Example 1: Had everything else working then needed a connection string or some such between my Visual Basic .NET code and SQL Server. Struggled with (1) and (2) full time for over a week, with frustration rising like a South Pacific volcano getting ready to erupt, finally reached by phone some relatively high executive who was surprised that anything so routine could be so difficult and quickly gave me the secret. Then my work raced ahead, no problems, and all my code worked fine.

Example 2: Wanted a way for occasional, simple, routine file copying between two computers on a LAN (local area network) from both being connected to the same cable modem. Looked at the old "NET SHARE" and "NET USE", encountered mostly unclear, obscure, undefined technical terminology, tried to make sense out of the obscure syntax diagrams, observed that apparently nearly none of the many combinations of claimed options actually worked, and eventually, from two weeks of full time work, like throwing mud against a wall to see what would stick, underhand, back spin, side arm, etc., did a lot of guessing about what could be wrong and why (mostly involving computer security), discovered that likely computer A might be able to initiate a read from computer B but no way could computer B initiate a write to computer A, etc., got somethings working, but still need to document the effort.

More problems on the horizon ahead:

Problem 1: How to have on one computer at least two instances of the operating system on separate (bootable) hard disks and be able routinely (a) to back-up to additional internal and/or external hard disks all of the installed instances or restore from those backups and (b) recover quickly in case any hard disk fails or any bootable instance becomes corrupted.

Problem 2: How to install PostGreSQL on Windows 7 Professional and/or Windows Server 2019 and get code in Visual Basic .NET to use PostGreSQL. Is there some good documentation?????? Will be thrilled to learn that in this case there is no problem!!!

Once (1) and (2) are out of the way and, as results, the basic tools are working, the APIs (application programming interfaces) are well documented, then the syntax and semantics of the programming languages are easy and the programming itself is the easy, short, sweet dessert after all the nonsense before. The heap data structure, B+-trees, key-value stores, the .NET platform invoke, matrix inversion and eigenvalues, the Gleason bound, .NET managed memory, semiphores for controlling multiple threads, base64 encoding, HTML, etc. -- all really simple, fast, easy. (1) and (2) -- well over 70% of the effort.

Re: Programming Is Mostly Thinking (2014)

#328
post #309

Earlier quoted context omitted.

can you clarify your comment with some examples, because i'm not sure what you mean, even whether you intend to disagree with the parent comment or agree with it

Lets take pending orders and paid for orders as an example. For both, there is a function to remove an order-line that looks the same. Many people would be tempted at that point, to abstract over pending and paid orders to have both reference the same function, via adding a base class of order, for example, because the code looks the same. But for a pending order, it means removing an item from the basket, while for…

i see, thank you!

Re: Programming Is Mostly Thinking (2014)

#329

Earlier quoted context omitted.

> I think he's actually describing Linus Torvalds there, who, legend has it, thought about Git for a month or so and when he was done thinking, he got to work coding and in six days delivered the finished product. And then, on the seventh day he rested. That sounds a bit weird. As I remember, linux developers were using semi-closed system called BitLocker (or something like that) for many years. For some reason the o…

Well, if you want to take what I said literally, it seems I need to explain.. My point is, he thought about it for some time before he was free to start the work, then he laid down the basics in less than a week, so he was able to start using Git to build Git, polished it for a while and then turned it over. Here's an interview with the man himself telling the story 10 years later, a very interesting read: https://ww…

[deleted]

Re: Programming Is Mostly Thinking (2014)

#330

“Programming is mostly thinking” is one of these things we tell ourselves like it is some deep truth but it’s the most unproductive of observations. Programming is thinking in the same exact way all knowledge work is thinking: - Design in all it’s forms is mostly thinking - Accounting is mostly thinking - Management in general is mostly thinking The meaningful difference is not the thinking, it’s what are you thinkin…

An important difference is that in programming, it is often better to do the same thing with less code (result).

I don't mean producing cryptic code-golf-style code, but the aspect that all the stuff you produce you have to maintain. This is certainly different from a novel author who doesn't care so much about maintenance and is probably more concerned about the emotions that his text is producing.

Post reply on HN