pandler
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.
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.
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.
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.
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!
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.
It’s not a silver bullet and requires A bit of overhead. I’m interested too to hear how other people manage the problem.
https://www.makersasylum.com/covid19/
Their open source face shield designs, which include different materials: https://github.com/MakersAsylumIndia/Covid-19
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 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.
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?
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.
For me personally, it started with a friend who would bum me cigarettes here and there, and I would partake for the sake of stepping outside with him.
What seemed like an innocuous “just one cigarette” here and there started to turn into cravings. It was all downhill from there.
I think of it as something like a reverse password manager; instead of "here's a website, what's my data", it's "here's a bit of information about myself, who has it?"
It's a pain keeping that list updated but at this point I'm so hooked on being able to see my personal info leak out into the world bit by bit that the friction is worth it.
I'm still trying to figure out what I should do with the data I have on myself, if anyone has any suggestions.
[1] That situation seems sketchy seeing it written down like that, so just want to explain that it's because I moved to a different country (address, phone, credit cards) and away from gmail at the same time.