Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I recommend that you stop loving your tools and focus on solving problems.


And I ask, why not both? It's gonna be a rough day at the job site hanging dry wall with a screwdriver.

There isn't some dichotomy that makes us choose between good tools and solving problems.


A screwdriver is not effective at that job, that’s the whole point. A good tool is a suitable and effective tool, not necessarily an aesthetically pleasant tool. Beauty of the tool is not a relevant metric


I'm not sure what you're talking about. You said to stop worrying about tools, and I gave an example where the tool does indeed matter, and then you agree with me but act like you're disagreeing.

> A good tool is a suitable and effective tool, not necessarily an aesthetically pleasant tool. Beauty of the tool is not a relevant metric

No one is hinging upon aesthetics. They simply come with tools that have been purposefully designed. I might suggest reading some architecture books, from the older architects like Frank Lloyd Wright, or books on complex systems about the relationship between form and function.


I’m clarifying my point. You understand my point now I’m sure. And yes there are many many programmers who get hung up on aesthetics


No, I don't understand your point because you said to stop loving your tools, which I don't agree with.


The charitable (and more reasonable) way to interpret 'loving your tools' is not 'liking your tools intensely' but rather 'don't enter into an exclusive romantic relationship with your preferred tools'.

Generally if you can prove your ability to solve problems you get more credibility when deciding the tech stack, but given your assertion elsewhere that "tools are often dictated by those less experienced or even unknowledgeable", then your original question is basically how to prove yourself better than the "middle of the bell curve" under an unfair system.

I mean, the points you raised there are probably factual, but it's apparently not a really helpful (to yourself) way to look at things. Generally smart people are able to surround themselves with similar people, and don't really need to find ways to convince unknowledgeable people that they're smart. Software engineering is a huge field and I'm sure you could find people who more resonate with you.

And sometimes it just takes some years for people to realize you are right.

All that said, I think on the tooling part, it all just boils down to taste. Some tastes are more refined, but they're largely subjective or situational.


hnfong explained it better than I did


paraphrasing Russ Ackoff, intelligent people don't aim to solve problems but to dissolve them, and the best way to do this is to build whatever it is you're building on excellent tools. We would have significantly fewer problems in the world of software if people started paying attention to the quality and mastery of their tools.


The issue is that programmers often focus on the aesthetic aspects of their tools. They like smalltalk and lisp because they are somehow elegant and beautiful. However this is a red herring. The only metric that should be considered is how effective the tool is for solving the problem. Discerning between utility and aesthetics of a tool is an essential skill for any programmer to learn


I liked Smalltalk because the language implementation provided source code for all the IDE tools: examples of how to build rich GUIs when that was new.

I liked Smalltalk because I could watch people working with a prototype and learn how to transform the work they were doing.

I liked Smalltalk with ENVY/Developer because I could see when someone created new unreleased editions of methods on classes that I'd changed, talk with them, resolve clashes, merge and release, in a tight development cycle.


Speaking for myself, utility plays a big role in how I perceive a tool in terms of aesthetics. It's not only about a language's grammar fitting in a business card and stuff like that.

Python and JavaScript are two languages that have been used for stuff they are obviously unsuitable for, at a vast scale.


Can you give an example of something Python has been used for that it’s not suitable for?


Scientific computing. I can't just write a "for" loop and expect it to perform. I have to use whatever is provided by packages which weren't written in it, or make a similar package myself.

I can't imagine any technical reason for this situation. Only perceived convenience and some kind of social dynamics.


No one brought up aesthetics except for you.


Yes, I know


> Russ Ackoff

Which book of his should I start with? Thanks for the reference.


The Art of Problem Solving is a good start given that most of his other work is more management oriented. But if you want an introduction to his kind of thinking, Thinking in Systems by Donella Meadows is fantastic as well.


Thanks for the suggestion! Yes, I'm familiar with Thinking in Systems and other systems thinkers but for whatever reason haven't read anything from Ackoff.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: