pandler

Thanks for keeping that service up and running! I think it’s been about 10 years since I found it and it’s been my go-to reference ever since. I’ll often get laughs from people when I share it as reference.

I’ve been building my wife a budget tracking dashboard for reporting on PPC ad campaigns.

At any given time, she’s working with any number of clients (directly or subcontracted, solo or as part of a team) who each have multiple, simultaneous marketing campaigns across any number of channels (google/meta/yelp/etc), each of which is running with different parameters. She spends a good amount of time simply aggregating data in spreadsheets for herself and for her clients.

Surprisingly we haven’t been able to find an existing service that fits her needs, so here I am.

It’s been fun for me to branch out a bit with my technology selections, focusing more on learning new things I want to learn over what would otherwise be the most practical (within reason) or familiar.

In addition to not enjoying it, I also don’t learn anything, and I think that makes it difficult to sustain anything in the middle of the spectrum between “I won’t even look at the code; vibes only” and advanced autocomplete.

My experience has been that it’s difficult to mostly vibe with an agent, but still be an active participant in the codebase. That feels especially true when I’m using tools, frameworks, etc that I’m not already familiar with. The vibing part of the process simultaneously doesn’t provide me with any deeper understanding or experience to be able to help guide or troubleshoot. Same thing for maintaining existing skills.

Somewhat unrelated to the point you’re making, something seems off about the results in that Glassdoor link.

Searching “computer science” in the jobs tab treats that as a keyword and shows results for a variety of job titles related to computer science. The salaries tab, however, seems to indicate it’s only collecting information about job titles that have “computer science” in the title.

> The work has received funding from the National Geographic Society and the U.S. National Institutes of Health, as better understanding adaptations to high altitude life is “potentially relevant in treating a number of human diseases that relate to... problems with oxygen delivery and oxygen utilization,” he says.

I often wonder how discoveries like this ultimately manifest into actionable technology. Are they studying cell structure? DNA? What does that process look like?

> The results could also aid doctors in treating altitude sickness and coping with life at high altitude or elsewhere where there are low levels of oxygen.

That makes me wonder if the end goal is some kind of pharmaceutical drug.

Very interesting nonetheless!

Agreed. With the very little context from the source article (admittedly), it feels like piling on to the whole Epic controversy.

I agree, but I try to stick to downgrading the comment/argument instead of the people themselves, because I’ve found it to be a pretty ubiquitous line of thought since I started noticing it.

> I would argue most relationships with coworkers aren't genuine. You might have a different metric for this, but mine is that when you change jobs, these relationships evaporate.

True, my relationship with my coworkers is scoped to my work environment, but I don't think that makes them not genuine. Rather, they are circumstantial, limited, and probably have a time limit on them. I don't value them any less for what they are. In fact, I embrace them for what they are: a meaningful aspect of the large chuck of my life that I spend working, even if they never exit outside of that realm.

Some of them do, like you say, slip through the cracks and do become friends outside of work.

As an analog, I spent about 5 years traveling and working remotely out of a backpack. I met A LOT of people, and I had many genuine and sometimes perspective-changing interactions with people. Most of them I don't keep in touch with anymore, but that doesn't devalue the time that I spent with them, even if we knew from the moment we met that we would only ever interact face-to-face for a few months.

Transactional and/or circumstantial and/or scoped to some time-bound aspect of your life != genuine

Giving OP the benefit of the doubt here, it seems like a straw man example off the top of their head, just to throw some ideas out there.

FYI your link is broken.

Agreed, the only mention of using different technology has come up in the current project is in discussions of Typescript vs plain JavaScript. That’s been the only bring-your-own-technology for the most part, since we’ve standardized on React and some shared libraries like Lodash.

We’ve primarily benefitted from the forced feature and team isolation (aka domain boundaries if you would), plus it gives teams more granular control over their deployments. So, pretty much just what you described.

Another benefit has been our ability to build once and share features across different applications, since we have a few of those for reasons. Teams can build out different “views” (roughly) for different use cases on different apps which share the core functionality.

We make heavy use of peer dependencies, so microfrontends rarely end up actually bundling their own dependencies. Build tools like rollup help with that.

It’s not a silver bullet and requires A bit of overhead. I’m interested too to hear how other people manage the problem.

> Nobody has any idea, they're just making it up as they go along.

Ha! I came here to say this, and I'm glad you share my opinion. I realize that you're speaking specifically about software estimates, so please excuse me while I take your statement out of context and generalize it to most everything that I've experienced working in software.

I'm biased in my views on this at this point, but I tend to notice people falling into two camps (on a spectrum of course): those who are most comfortable with well-defined tasks and low uncertainty, and those who are comfortable making stuff up and running with it. That's a rough, one-dimensional reduction of many qualities, including creativity, certain types of critical thinking, pragmatism, "self-starter"-ness, enthusiasm, etc. In equilibrium, it's the people who are able to distill uncertainty into something resembling certainty that ultimately provide tasks for the people less comfortable with unknowns.

Corollary to that is the idea that "correct" is not binary but rather a measure of effectiveness by any number of shifting metrics (e.g. performance, readability/maintainability, "correctness", time and money cost, defect tolerance; all under the general umbrella of priorities).

It's one of the things I try to impress most upon junior developers that I mentor, especially when they are just out of bootcamp and haven't learned yet that most problems aren't well defined and don't have an answer in the back of the book, if you would. Essentially, our job is to "make stuff up": always "how", and often "what".

> I think the old way is simpler in the sense of building on fewer concepts, and therefore allowing an easier learning curve

I would disagree with that premise. From my own experience and from having mentored developers on class components (so like ~7 data points), I'd say it's far easier to reason about state flow with hooks than lifecycle methods. That's an important point, because I see far more bugs with incorrect or incomplete state flow than I see with component lifecycles.

Hooks are simply easier to reason about. With hooks, you read the code top to bottom. Then, something changes either with the data or in response to user input, and then you read the code top to bottom again with that new state.

The only learning curve there is to understanding the basic premise of hooks is that "if this value is different from the last time you read the code top-to-bottom, then re-read/execute this code block"

> If using hooks allowed developers to avoid knowing the React component lifecycle, an argument could be made that they provide a simpler alternative, but I don't think anybody is going to get very far without being forced to learn about the component lifecycle. If someone were to say, "The React lifecycle is hard to understand, so use hooks instead," that would be a false promise.

That is exactly my premise, and I don't think it's a false one. Since moving to hooks, I can't remember the last time I had to care about the React lifecycle. Again, the mental model is "Read the code top to bottom; something changes; read the code from top to bottom" ad infinitum.

Yes there are situations where class components provide more intimate control (componentWillUnmount comes to mind since I'm not aware of a hook for that), but are we really optimizing the majority of our code for exceptional cases?

Another data point: I haven't seen functional components turn into a complete mess from inattentive developers in the same way I've seen class components turn into indecipherable setState tangled messes. The only time I've experienced the pressure of sifting through component lifecycles under the pressure of debugging a time-sensitive production isssue is because I was using component lifecycles in the first place. It's a moot point.