"Thinking out loud”… that’s how I view the process of writing code. I start with a concept, then think my way through the solution by writing code.
Programming Is Mostly Thinking (2014)
261–270 of 339 posts
Re: Programming Is Mostly Thinking (2014)
#262Earlier 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.
In my mind this is breaking down the problem into a relevant data structure and algorithms that operate on that data structure. If for instance you used a tree but were constantly looking up an index in the tree you likely needed a flat array instead. The most basic example of this is sorting, obviously but the same basic concepts apply to many many problems. I think the issue that happens in modern times, specially…
> I think the issue that happens in modern times, specially in webdev, is we aren't actually solving problems. We are just glueing services together and marshalling data around which fundamentally doesn't need to be algorithmic...
This is true and is the cause of much frustration everywhere. Employers want “good” devs, so they do complicated interviews testing advanced coding ability. And then the actual workload is equal parts gluing CRUD components together, cosmetic changes to keep stakeholders happy, and standing round the water cooler raging at all the organisational things you can’t change.
Re: Programming Is Mostly Thinking (2014)
#263Earlier quoted context omitted.
Does it really take four hours to sharpen an axe? I've never done it.
10/20 minutes to sharpen a pretty dull kitchen knife with some decent whetstones. Also, as someone famous once said: if I had 4 hours to sharpen an axe, I'd spend 2 hours preparing the whetstones.
If I had 2 hours to prepare whetstones I’d do 1 hour of billable work and then order some whetstones online.
Re: Programming Is Mostly Thinking (2014)
#264Great 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…
There's more than one way to do it.
How I work:
- First I make a very general design of modules, taking into account how they are going to communicate with each other, all based in experience with previous systems.
- I foresee problematic parts, usually integration points, and write simple programs to validate assumptions and test performance.
- I write a skeleton for the main program with a dumbed-down GUI.
From that point on, I develop each module and now, yes, there's a lot of thinking in advance.
Re: Programming Is Mostly Thinking (2014)
#265Earlier quoted context omitted.
writing it is not expensive. however, fixing the same bug in all the redundant reimplementations, adding the same feature to all of them, and keeping straight the minor differences between them, is expensive
Not only fixing the same bug twice, but also fixing bugs that happen because of using the same functionality in different places. For example, possible inconsistency that results from maintaining state in multiple different locations can be a nightmare, esp. in hard-to-debug systems like highly parallelized or distributed architecture.
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.
Re: Programming Is Mostly Thinking (2014)
#266Earlier 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 tend to see this as a sign that a design is still too complicated. Keep simplifying, which may include splitting into components that are separately easy to keep in your head. This is really important for maintenance later on. If it's too complicated now to keep in your head, how will you ever have a chance to maintain it 3 years down the line? Or explain it to somebody else?
[deleted]
Re: Programming Is Mostly Thinking (2014)
#267Off topic. I'm not a developer but I do write code at work, on which some important internal processes depend. I get the impression that most people don't see what I do as work, engaged as they are in "busy" work. So I'm glad when I read things like this that my struggles are those of a real developer.
Sounds like you are a "real developer". Don't sell yourself short.
Re: Programming Is Mostly Thinking (2014)
#268I thought it was 90% debugging? Perhaps it is 90% of the non-debugging that is thinking!
Re: Programming Is Mostly Thinking (2014)
#269Programming is mostly thinking just like many other knowledge related jobs, it's nothing special. This analogy can be used for most design related jobs, not just software.
If I had my client report deleted today, I could rewrite that report in nearly half the time the next day because I remember the way in which I structured the report, the sentences that flowed that didn't and the way I conveyed the findings in a neutral way.
No different to designing a physical product. You might see the outcome, but you don't see the numerous design iterations and compromises that came along the way which speak to the design that came out the end.
Furthermore, there are going to be programmers that can write more code with less thought, because they might have many years of pre-thought knowledge and understanding that allows them to execute faster.
This article sounds like it was written for a manager that doesn't see the value in the work performed, or simply doesn't understand design related work.
Re: Programming Is Mostly Thinking (2014)
#270Developers need to learn how to think algorithmically. I still spend most of my time writing pseudocode and making diagrams (before with pen and paper, now with my iPad). It's the programmers' version of the Abraham Lincoln's quote "Give me six hours to chop down a tree and I will spend the first four sharpening the axe."
it's an odd analogy because programs are complex systems and involve interaction between countless of people. With large software projects you don't even know where you want to go or what's going to happen until you work. A large project doesn't fit into some pre-planned algorithm in anyone's head, it's a living thing. diagrams and this kind of planning is mostly a waste of time to be honest. You just need to start t…
> You just need to start to work, and rework if necessary
And making changes on paper is cheaper than in code.