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.
I will always have a soft spot in my heart for Django, the python web framework, even though I don’t use it anymore. https://www.djangoproject.com/
When I was still learning to code, I spent hours and hours and hours poking around the Django source code. In particular I was fascinated by the metaprogramming used in the Model and Query objects, and I ended up learning a ton about how Python works under the hood.
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.
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
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.
Cool to see more news from Mumbai. I've been following a close friend of mine (also in Mumbai) on various social media as he works on his goal of fabricating "100,000 M-19 Face Shields for India" in his maker space.
> 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.
> I find that writing _something_ can help me to get a feel for a problem. Start, then sitting back and thinking about it, helps me to move towards a better solution faster.
That summarizes the struggle that I have with TDD. I guess you could argue that I’m doing TDD wrong, but most of the time I feel like I don’t know what I’m going to be writing until I write it.
Basically most of my coding I feel like I’m prototyping until I iterate a few times and arrive at a solution I’m happy with and understand where the boundaries between various functions need to be. Until then, how am I supposed to pre-empt my solution with tests?
I have a beard precisely because it’s trivial for me to maintain. I trim it down to 3/8 inch maybe once every two weeks, and clean up my neck in 30 seconds with the trimmer about once a week.
Yeah sure it’s not a flowing 5 inch beard, but it’s still a beard. Point is, short beards require much less maintenance to consistently look well groomed than shaving every day in my experience.
I’m sure it’s nothing like the south east, but it gets pretty hot, mostly in July and August. Living in a hotter but drier climate now (which is on the whole more comfortable than back in NH), I realize that the humidity played an important part in it feeling hot and uncomfortable. Mid 80s in dry heat is many times more bearable than mid 80s in humid weather, and the same thing goes for the cold too.
And I also just verified by checking myself against some known Jira dashboards and searching for some of the search queries he provided... I'm not sure what there isn't to trust when he tells you exactly how to verify the information.