41–50 of 165 posts
But I feel depressed every time I use Terraform. I see why it is useful, good etc. But I just enjoy it least of all the programming activities. Pulumi isn't much better. I feel IaC done that way isn't the way we will settle on long term.
At the last hackathon I went to I was sitting in the audience at the presentation at the end with one teammate while the other one was upstairs pounding away at last minute revisions. We were scheduled last but I still had to make excuses to the organizers.
He showed up with something that basically worked but I kept cool under pressure, made sure I didn't commit to anything until I was sure about it, and used good showmanship. We were all shocked when we won the 'player's choice' award. Mind you, it helped that he was experienced at writing platformers in Unity and the other student could draw, but thanks to my showmanship people saw everything that didn't worked and didn't notice the bugs and people were left with the impression that 'wow that looked like a polished game' whereas the main author said 'I don't think I'd want to play it' afterwards. My continuous push towards a 'minimum viable product' combined with their push to make something that looked polish really helped that showmanship work.
This is one of the things that I’ve tried really hard to impress upon engineers new and old while working on various projects, and IMO it applies to just about every layer of the stack; ultimately everything flows up into the UX. This vibe was pervasive at Apple and could be taken more or less for granted, but elsewhere it’s all over the place. And, like, sure, there are projects and industries where this doesn’t mat…
The current vibe at Apple is "we want you to be an obedient worker".
[0] https://systems-souls-society.com/what-is-this-the-case-for-...
I dunno. A good demo is all about the feeling it gives. One thing I got out of my adventures in startup land is how to go up on stage and demo some software that barely works and make it look like a million bucks. At the last hackathon I went to I was sitting in the audience at the presentation at the end with one teammate while the other one was upstairs pounding away at last minute revisions. We were scheduled last…
> You have to feel it. The corporate machine does not feel it. It can't be bargained with. It can't be reasoned with. It doesn't feel pity, or remorse, or fear. And it absolutely will not stop... ever, until you are dead.
Oh, i thought it was a satirical critique of how arbitrary promotion criteria can be. Turns out someone is seriously claiming that someone else "doesn't not feel the right way" about the work they do, and THAT is their core problem. Ha. Well, at least the author feels that they are feeling the right way, good for them I guess.
But I feel depressed every time I use Terraform. I see why it is useful, good etc. But I just enjoy it least of all the programming activities. Pulumi isn't much better. I feel IaC done that way isn't the way we will settle on long term.
The state file thing gets a relatively large part of the hate but it's that and the limitations of the DSL that make the DAG possible and useful. Pulumi and all the other wrappers don't solve this, though they can plausibly solve the "closer to programming" problem and I'm sure that has a valid audience.
I guess what I'm saying is, I think it'll stick around and we will in fact settle on it for a large part of operational work. I'll add that I also think k8s should die a quiet death and _that_ will be seen in retrospect as a necessary step to something better.
For as much as the author may get roasted for stating the obvious, I've often seen this "measure everything" mindset, coming from those you'd think should know better than that. I've even seen this stupidity in myself sometimes. In a way it's funny how you can get so lost on the numbers that you forget about the thing .
Measuring and feeling are not mutually exclusive. This is just the frame that the author is trying to prop up in order to sell us their shallow, meaningless piece. I wouldn’t normally even comment something like this about someone’s article, but I see this pattern a lot in “influencer” content that people sometimes share with me and I am worried that if we don’t point it out, we will lose our ability to spot nonsense…
They are not mutually exclusive, but they compete to a degree. If someone's time is mostly spent on what can be measured, they can't spend time on "common sense" or investigative work that is less easily tracked. At the end of they day, trying to measure everything makes as much sense as trying to document every line of code. (Most of this, naturally, also applies the other way around).
> This is just the frame that the author is trying to prop up in order to sell us their shallow, meaningless piece.
> I see this pattern a lot in “influencer” content that people sometimes share with me
I think a lot of the shallowness is from blogs or HN being a public, persistent, broadcast written media. In a face to face conversation, you can generally follow up and share more specifics and nuance without fear of getting a bad reputation.
If anything I think the bias is the other way around, on the Internet whatever you write can get cherry-picked and framed to make you appear terrible, in person it's much easier to get a fair sample.
Smart move by Mitchell to omit (in his opinion) _why_ you have to feel it, as evidenced by the spread interpretation in the comments. In my opinion, you have to “feel it” in order to do your best work. However(!), and also in my opinion, you shouldn’t always strive to be in a position where you “feel it”. While it is important to spend most of one’s life feeling it / doing their best work in order to be fulfilled, th…
> Working with passion fuels a level of intensity and emotional involvement that can take a while to recover from if you don’t get the result (read: success) you desired.
The number of IQ points doesn't really matter but this is about feel. With passion you're much more likely to dig in. By digging in you're more likely to see subtle issues that can result in drastically different outcomes (the more complex something is, the more likely such issues exist). You care about the thing working and so you care about finding out when it doesn't work.
On the other hand, if you have no passion you just go through the motions. You spend less time thinking. It passes the tests? Okay great, let's move on, "it works, so who cares?" In this situation you care less about the thing working and more about getting the task done.
I feel like the second attitude is becoming much more common. I'm sure there are a ton of reasons why but I feel like one of these is that complexity has just exploded. An unfortunate fact is that you can make things too simple. Little errors compound to become big errors that are difficult to wrangle. I think we've gotten to a point where there's so much (often hidden) complexity that we are constantly being overwhelmed, making it harder to care, creating a dangerous feedback loop.
Every good problem solver knows that the best way to tackle a problem is to break it down into bite sized and simpler pieces. But the flip side of this is that every big problem is caused by the accumulation of many little problems. For some reason we have a much harder time thinking in this direction. For this reason I think we need to stress the importance of the little things[0]. It is also important to remember that when solving the big problem that solving each little problem is not enough. That only works if they are independent. You may want to start out treating them as such but that's why this tends to become an iterative process, because as you converge to solving the larger problem these hidden complexities start to reveal themselves. So solving small problems is a defensive strategy.
[0] This can easily be misread. I am not insisting that everyone be a perfectionist. What I've said is far easier said than done. Perfection does not exist, there is always something wrong. The question is much more about bounding that error and keeping it small. It is about recognizing these issues and keeping track of them. More important than solving problems is the recognition of them. After all, it is incredibly difficult to solve problems you don't know exist. By keeping track of these things you can better triage tasks. Even a few comments in the code stating what assumptions are made or stating the conditions that the code is expected to run on will save you tons of headaches in the future. A trivial amount of work in the moment can pay enormous dividends when given enough time.