Live data from Hacker News

Programming Is Mostly Thinking (2014)

agileotter.blogspot.com

291–300 of 339 posts

Re: Programming Is Mostly Thinking (2014)

#291
post #159
post #83

Earlier quoted context omitted.

I often feel that having a "comfortable" keyboard/mouse/monitor is more important than a fast CPU or a fancy graphics card - just because of that slight extra feeling of pleasure/ease that lasts all day long :-). The advantage of them is that my monitors and keyboards usually last a long time so putting money into them is not as wasteful as putting it into some other components. One thing that surprised me though is…

May I ask which brand of KVM you selected? I have a Dell laptop and want a "docking" configuration for my desk, the simpler the better.

It was a very cheap thing off Amazon. I'm in the UK so you might not have it - the brand name is "VPFET KVM Switch 2x1" and it has 4 usb, 1 HDMI outputs and 2x(1 HDMI,1 usb) inputs.

It's the cheapest in their range, I think (about £30) - they have better ones.

Not massively flexible. Has a clicker switch which you could put on the floor if you wanted to let you flip displays. Not super fast at switching.....but it does the job for me. YMMV!

I use a 32-inch Viewsonic monitor with this. It's the most expensive monitor I've ever bought but it's nothing special when you look at what's out there. I't just lovely to use. :-) I think a purist would complain bitterly about refresh rates or whatever but I just love it and I spend my time reading web pages or code or watching the odd video.

Re: Programming Is Mostly Thinking (2014)

#292
I studied CS and taught programming 101.

In my experience, the main issue with learning to code are all the contexts you have to remember.

There is the static type level and the runtime level, all the scopes (class, object, function, nested functions, closures, etc.), the different machines (client, server, or even multiple servers, etc.)

That's probably the reason why most devs start with dynamic languages and frontend/mobile. It can get just as complex as backend development, but at least you can eliminate a bunch of contexts when starting to code, learn what's left and then add contexts later.

Re: Programming Is Mostly Thinking (2014)

#293
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…

Also not every task requires deep thought. If you are writing some CRUD, it is usually not going to be all that much thinking, but more touching the keyboard.

Re: Programming Is Mostly Thinking (2014)

#294
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…

Also not every task requires deep thought. If you are writing some CRUD, it is usually not going to be all that much thinking, but more touching the keyboard.

I wish I had thought a little more about this CRUD.

I hand wrote HTML forms and that was not a great plan. I made a dialog generator class in about a half hour that replaced dozens of CreatePermission.html type garbage I wrote a decade ago.

Re: Programming Is Mostly Thinking (2014)

#295
post #113
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…

I think first on a macro level, and use mind maps and diagrams to keep things linked and organised. As I've grown older, the importance of architecture over micro decision has become blindingly apparent. The micro can be optimised. Macro level decisions are often permanent.

I think this is probably a lot of the value of YAGNI.

The more crap you add the harder it is to fix bad architecture.

And the crap is often stuff that would be trivial to add if the bad architecture weren't there, so if you fix that you can add the feature when you need it in a week.

Re: Programming Is Mostly Thinking (2014)

#296
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…

Germans say "probieren geht über studieren" which means, rather try it than think it too much.

Re: Programming Is Mostly Thinking (2014)

#297
post #241

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…

>> …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. How very biblical. “And Torwalds saw everything that he had made, and behold, it was very good. And there was evening, and there was morning—the sixth day.”

You've were downvoted but that part made me smile for the same reason :-)

> The seventh day he rested

This is obviously Sunday :-)

Re: Programming Is Mostly Thinking (2014)

#298
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…

(not so much of a reply, but more of my thoughts on the discussion in the replies)

I would say the topic is two-sided.

The first is when we do greenfield development (maybe, of some new part of an already existent software): the domain is not really well known and the direction of the future development is even less so. So, there is not much to think about: document what is known, make a rough layout of the system, and go coding. Too much investing in the design at the early stages may result in something (a) overcomplicated, (b) missing very important parts of the domain and thus irrelevant to the problem, (c) having nothing to do with how the software will evolve.

The second (and it is that side I think the post is about) is when we change some already working part. This time it pays hugely to ponder on how to best accommodate the change (and other information the request to make this change brings to our understanding of the domain) into the software before jumping to code. This way I've managed to reduce what was initially thought to take days (if not weeks) of coding to writing just a couple of lines or even renaming an input field in our UI. No amount of exploratory coding of the initial solution would result in such tremendous savings in development time and software complexity.

Re: Programming Is Mostly Thinking (2014)

#299

I'm confident enough to tout this number as effectively true, though I should mention that no company I work with has so far been willing to delete a whole day's work to prove or disprove this experiment yet. Long ago when I was much more tolerant, I had a boss that would review all code changes every night and delete anything he didn't like. This same boss also believed that version control was overcomplicated and d…

Anyone who has made seious use of Microsoft Office products in the 00's and 10's knows these things to be true (or they reflexively click save every 5-10 minutes).
Post reply on HN