My nights and weekends project at the moment is a virtual staging tool for real estate agents.
I'm focusing on the South African market (I know a bunch of agents and I've noticed an increase of very obviously ChatGPT generated images on property listing websites)
My hope is that I can own a nice slice of the listing marketing workflow:
- Creating great, but realistic staging images for listing websites
- Improve property descriptions and copy
There is some early interest from agents, hoping to start marketing properly this week!
I'm a really passionate engineer/leader with a mix of experience across insurance, payroll and SaaS. I've worked in large corps and startups, with a few freelancing stints along the way. I'm always hacking on my own stuff in the background and looking for interesting problems. Good at working with really high ambiguity and figuring things out.
I tried something similar a while back. It made me feel like I was doing really we;; at prioritising my work, but it's honestly a hard thing to do well and without over-engineering prioritisation.
These days I just have a list of weekly objectives (TODOs), and a daily list of things that I'm "doing". The doing list is based mostly on gut feel about what's important right now, and is in part - based on what my team / the business feels is important right now.
All the things in the weekly objective list are always high priority / important, if it isn't, then it doesn't go on a list.
OP here. I think it serves as a loanword, but I concede that linking to an _English_ dictionary can blur the point I was trying to make. Edited for clarity, thanks!
OP here - I think your interpretation (the former) is pretty spot on. I also think the less charitable interpretation is not _exactly_ wrong. The title and repetition of "Be Less Technical" are definitely not devoid of "click thirst" - but the content is intended to be more in line with "we need to find ways to talk to each other, irrespective of whether we talk to customers or compilers".
I'm flattered that the OP took an interest in my comment, and when I said "less" click-thirsty I hope I didn't come off too judgemental: whether we admit it or not we're all pretty well wired-up for the engagement dopamine hit at this point, including me and my comment.
Given that you've clarified the point you were making was the one I hoped: I am interested in hearing more from you and I would gently discourage that particular writing style. Your post could have been called, just for the sake of argument, "Work Technical, Speak in Plain Language" or something to that effect.
There is this, I'll say it, dysfunction, where certain folks in the software business are trying to create a (high-paying) career track that is adjacent to deeply technical stuff but not really touching it. That needs to be drowned in a bathtub.
Anyone smart enough to write an optimizing compiler is smart enough to explain how one works, at least in outline, to a layperson. There is no need for a middle-man layer of blubber between the people who need to know why to buy or not buy one, and the person who knows how to write one.
> Anyone smart enough to write an optimizing compiler is smart enough to explain how one works, at least in outline, to a layperson. There is no need for a middle-man layer of blubber between the people who need to know why to buy or not buy one, and the person who knows how to write one.
I don't think that conclusion follows from the premise. I could also mop the floor and clean the windows at work, but that doesn't mean that it would benefit the company overall. Similarly, just that engineers could in theory explain the thing they do to e.g. a customer does not mean that they should spend their time doing this. *
There's further nuance in that (in my experience) engineers tend to be, by default, not great at communicating at the right level with a lay-person (which is more or less the point of the article), and that hiring people to interface between e.g. customers and engineers comes with pitfalls and can go wrong (your point, I believe). I personally think it's best if someone who presents products to customers has a deep engineering background and has transitioned into their customer-facing role from there. But if you need to visit more customers to make more sales, hiring more sales people instead of drawing from your engineering department is probably a wise choice.
I say these things as an engineer in the trenches.
* To be clear, I have no intention of disparaging either job.
I mean to be clear, I'm not drawing a conclusion from a premise: I'm making an assertion, and in fairness, that assertion is trivially false by virtue of invoking words like "anyone" and phrases like "no need". Nothing exists `forall` what I said. I'm also aware that the assertion is a flashpoint for a lot of people and extremely controversial, even when you relax propositional logic enough to admit the trivial counter-examples (intelligence is clearly not some nice, neat scalar quantity).
Nonetheless I think that everyone knows what I'm saying: which is that they're are more than enough people who can both do deep technical work and wear clothes well and work a fucking powerpoint that the industry doesn't need to resort to employing nontechnical people in roles that require both, and that outside of certain verticals, someone who knows their shit but makes iffy eye contact or stutters is still a better person to put in front of the slide deck than a slick, charismatic figure with a dim grasp of the subject matter. It's nowhere near the either/or that it is so frequently presented as, and even when presented with that either/or choice I'll take the competent nerd unless I'm selling IBM z-series boxes to credit unions or something like that.
Given that OP is on the thread I'll leave it to them to clarify the point of the article, but I will point that my reference was to a classic parody of this whole "good with people" trope that was already darkly funny long before pervasive cloud services, the vastly increased prestige in software engineering roles, exploding FAANG engineer salaries, and all the other things that have people with the right look signing up for CS classes in droves [0].
Love Obsidian as well, for about 1y now. I have a tech background, but typescript and aws serverless were new to me, so I decided to learn-in-public.
Regarding categorization (and design), I was inspired by Julia's web: https://jvns.ca/
About four years. I'm averaging around 10k lines per year in the journal, but I tend to separate large logs out into a separate file in the logs directory and then link to it from the main file.
