51–60 of 356 posts
I didn't think there was many of us out there ;)
I like cool new tools, but my obsession is solving the problem in the most effective manner. Too often I see people starting with the tool and then trying to shape the problem to fit the tool.
is there a video of this being presented somewhere?
Earlier quoted context omitted.
Learning from the past isn't to prevent you from reinventing the wheel but from reinventing the pothole.
Nothing wrong with reinventing potholes... https://www.indy100.com/article/this-man-is-painting-penises...
What the original saying is about is pretty clear from the words "condemned" or "doomed" to repeat it (depending on the version). [0]
The saying is not about "reinventing the wheel" as in "refining/reinventing something already positive". It's trying to steer people away from major mistakes. Like ones that lead to great human tragedies and loss. Of course, everything can scale, it can affect an individual or the whole world.
[0] https://en.wikiquote.org/wiki/George_Santayana#Vol._I,_Reaso...
Earlier quoted context omitted.
For me, change happens when I see a real improvement in almost every way possible which is usually determined by building a few things and letting my brain simmer on the technology as a whole so I can look at it with a logical and unbiased perspective. I remember looking at Node when it first came out and got mildly excited, but that excitement quickly went away after writing a couple of small apps with it. It just w…
Go is a compiled language and Ruby/Python are interpreted scripting languages. There are domains where it's a much more appropriate choice (distributing binaries, performance sensitive code). The type system is also quite nice vs. dynamic typing (in most situations). It's weird to see people comparing Go and Python in this thread as they solve entirely different problems and shouldn't be interchangeable, not due to d…
Yes but when Go first came out, a lot of people jumped on the bandwagon and started proposing they would use Go for web applications too. There's definitely some overlap in building web services with Go and Python so I wouldn't say they solve completely different problems.
Go and Python are also pretty related for command line apps too. You could totally use either one to build a CLI tool.
Another case of someone discovering, after 10+ years in tech, that code is a liability and you're supposed to solve problems instead of chasing trends and padding the resume. Great that he's spreading the word!
Code is not "a liability". It is a tool that can be used masterfully or utterly abused. Every craftsman has to invest in their tools. And for someone to truly master their craft they must sometimes hone their tool skills speculatively, without short-term gain, and by sacrificing the time and attention used for other things, like actual projects. If everyone just obeyed their project manager and always focused 100% on…
Earlier quoted context omitted.
Code is not "a liability". It is a tool that can be used masterfully or utterly abused. Every craftsman has to invest in their tools. And for someone to truly master their craft they must sometimes hone their tool skills speculatively, without short-term gain, and by sacrificing the time and attention used for other things, like actual projects. If everyone just obeyed their project manager and always focused 100% on…
Exactly, if it was a liability, you would simply delete it, because unlike real liabilities, it's legal.
I often think about this part, in particular:
>Then we walked away. We didn’t do anything related to activity feeds for years after that. We barely even thought about it.
>Then one day I said, “hey, I wonder how activity feeds is doing.” And I looked at it and was surprised to discover that in the time since we’d launched it, the usage had increased by a factor of 20. And as far as I could tell it was totally fine.
>The fact that 2,000% more people could be using activity feeds and we didn’t even have any idea that it was happening is certainly the greatest purely technical achievement of my career.
I get a huge kick from making something, and then forgetting about it. For me, implementing something that provides value with near-zero maintenance for years is the ultimate sign that I've done well.
I appreciate the idea of mastering a language or technology. It is often much easier than adopting something new.
But the main reason for adopting something new, is to make doing something much easier. That 'something' is often a call to solve a new problem.
I feel you generally come to understand why you should adopt a technology, after mastering your current set of tools.
If we were to really take to this idea of maximising the tools that are already available, then we probably all still deploy applications over FTP.
I think the two most valuable take-aways for me, are the importance of discussion, and the desire to have as small a number of dependencies as possible.
Interesting… most of the motivation to use new tech is that it enables me to solve problems more efficiently. When you use older, but more established technology, its limitations still hold back the problem solving a bit. This is especially hard to take when I know there are better solutions out there. And it also costs more time & money. There probably is a pain point somewhere, where it makes sense to switch. I did…