> left inner join
While I do appreciate this joke (and I do hope this is a joke), I've recently had a project majorly held up because a lead dev didn't understand SQL. It's great to admit gaps but it's equally important to close those gaps.
> As a hiring manager I interviewed software engineers and tried to filter for object-oriented knowledge. Retroactively, it’s clear I was hypocritical.
As some one who has been on the other side of "rejected by an interviewer who didn't understand the thing they've interviewed you about" I, again, appreciate the transparency, but I'm not entirely feeling that the lesson has been learned in the case.
There was a time in my life where I felt ashamed that I didn't know calculus... so I learned calculus and my life has been better for it. While refusing to admit ignorance of a topic is particular problem in tech, confessing that you don't know something and gleefully stopping there is not much better. Holding people up to a standard you do not hold yourself to is a major problem in this field. The technical people I've learned the most from hold you to a high standard and hold themselves to an even higher one.
Of course not every engineer has to hold themselves to a high standard, but if you want to write a blog about a topic, then part of the requirements here is that you do hold yourself to a high standard. Yes, we all have gaps, and we shouldn't let shame get in the way of learning, but we shouldn't let shamelessness about what we don't know limit us either.
I am indeed learning, working to close those gaps.
For automated testing, I'm in the middle of reading Developer Testing by Alexander Tarlinder, with xUnit Test Patterns coming close behind. I'm also working through Test-Driven Development: By Example with my wife as we have time.
For SQL, I read *Grokking Relational Database Design* by Qiang Hao last winter, and I started *SQL Queries for Mere Mortals* by John Viescas this week. Sadly, my flub with "left inner join" was not a joke.
> confessing that you don't know something and gleefully stopping there is not much better [...] we shouldn't let shamelessness about what we don't know limit us either
I promise you, this was not gleeful and this was not shameless. Shame and fear affected me for months on these issues. And I'm not stopping there... From the end of the article: "I’m going to continue to work on skill building, but now I feel free to write about it. If [...] you’d like to help me fill [my knowledge gaps], [...]"
> if you want to write a blog about a topic, then part of the requirements here is that you do hold yourself to a high standard
A high standard of writing, maybe. But plenty of great stories come from those who are striving for a high standard, not just those already in the upper echelon. It's what makes this place different from academic journals.
Not exactly your main point, but where’d you go to learn calculus? I did the usual classes in high school but none since, and I’d love to develop a better appreciation for it.
Youtube
About as helpful an answer as “book”
Every time that I read this about remote work, all I can think is how much I miss IRC and the culture that came from it.
We were doing remote work effectively decades ago. Don't have hallway conversations to fix bugs? Easy, just post your problems on the team chat and someone (often one of several people) would love to drop by to help.
I'm not sure exactly all of the forces that have led to this changing so much, but I'm certain that merely blaming "remote work" isn't it.
Somehow we were better at using remote tools while literally in the same office than some teams are at using them now while fully remote.
> Somehow we were better at using remote tools while literally in the same office than some teams are at using them now while fully remote.
I couldn't agree more. I pushed to get the place I worked for to use Slack when it first launched, moving us off AIM (ha!). Our use of Slack when we shared an office in the twenty-teens was so much better than the use I've seen of Slack/competitors on fully-remote teams.
I wonder if it's because the failure mode was, as you said, to "drop by." Now the failure mode is... just failure.
> Somehow we were better at using remote tools while literally in the same office than some teams are at using them now while fully remote.
This is sort of the point. Remote tools work great when you have spent a lot of time building relationships and rapport with the people involved. That's hard to do in professional settings, and extremely hard to do in remote professional settings.
Letting teams that know each other well work remotely works great. Building teams remotely is very hard.
I'm a diehard for remote work, but we have to be realistic abouts limitations.
Electronic chat is really not the same as face-to-face communication. Neither are video calls.
Of course it's not the same, that's the point. I personally prefer the async, chat based mediums I've used since I was a child. Some of my coworkers have disabilities that make conversational typing difficult and prefer video calls as a result.
Consider the effort to accommodate those preferences though. Accommodating a video call preference is easy. Same for chat. Accommodating a preference for face-to-face requires spending an hour (2x average US commute) traveling to meet you. That's quite a significant ask of the other person.
For me, electronic chat is better most of the time.
Everyone is different. I vastly prefer email over chat, but also wouldn't want to live without the occasional face-to-face.
"Everyone is different" is my point. Face to face once in a while is nice, though I don't care so much about having it very often with my colleagues in a professional setting.
My knowledge-gap confession: even after many years with the languages, I can't write a main() in Python or Java without looking up the format.
I’ve spent so much time in both the .NET and JS worlds that I can't even begin to count how many times I’ve typed `Where` when I meant `filter` or vice versa.
So many things like that!
I don't know if I could tell you with confidence the proper way to get a string length in any language. Is it a global function or an object method or property? Is it length or count or size? I have to look it up or rely on intellisense every time. I do too much bouncing between languages.
Well, I know it in BASIC. Len().
[delayed]
With Java 24 it’s now:
void main() { }Not if you want to handle arguments?
What, `def main():`? Or do you mean the __name__ == "__main__" thing for distinguishing whether the code was imported?
I can successfully type "def main()" and not "function main()", unless I'm switching between JavaScript and Python and forget which language I'm in :-). It's the if statement with all the underscores that I need to check every time.
Continuing the confessions: I do php.net/<function_name> at least twice a day
Is that a bad thing? I also call man <libc function> several times per day, most times I think I already know the calling semantics, but there is always some nitpick about the calling semantics or a bug description, that I didn't had in mind.
It's the main benefit of Rust ;)
(obviously it's not but it is super nice that main in Rust is just:)
fn main() { }"Knowledge means knowing where it is written down."
Like the post overall, but the last section is a bit weird for "confessions" as it's all HIGHLY subjective. For example, I worked at a company where no one worked from home and we paired 100% of the time. When COVID hit, we started pairing over Tuple and I found it to be a superior experience to pairing in person (Tuple's drawing and attention drawing tools are far more accurate than my finger, I can use my own keyboard the odd time I want to control my pair's computer, and there are no office distractions of other pairs in the same room are benefits that come to mind). I continued to enjoy (and prefer) it for the 1.5 years I stayed after lockdown.
All the confessions are highly subjective. If someone tried a refactor like the one at https://refactoring.com/catalog/replaceConditionalWithPolymo... there is a decent chance it should get picked up and reverted on code review.
Taking a switch statement and spreading it out over 3x classes is not a general improvement, it is very context specific. It makes the code difficult to navigate because what used to all be in one spot and easy to read is now spread out who-knows-where and there might be a special case lurking somewhere.
I suppose I included the last section as a "confession" because I spent years pre-pandemic wishing I could go remote, talking loudly about how open office spaces were bad, etc. That, plus it's embarrassing to admit that I dislike remote work even though I am a remote worker. And not just a remote worker, but an enfranchised remote worker living 3 hours away from the nearest city with an international airport. I made the mistake of rebuilding my life around remote work before I had experienced it long-term.
Awfully nice, isn't it? You get all the privileges of being a remote worker, while "confessing" that remote work sucks to upper management who read your blog, giving them justification to deny other people the same opportunity you have. If you genuinely believe remote work sucks, you should own up to it, sell your property, and move to a city rather than reaping the benefits of it to the extent of your entire life being dependent on it while talking about how bad it is. The fact that you haven't done that indicates to me that you actually quite enjoy the benefits more than you suffer the drawbacks, but aren't acknowledging it, instead choosing to denigrate remote work for having any drawbacks at all.
I appreciate the author being vulnerable like this in a public setting. It's easy to see why it would be scary, especially since admitting being wrong or not knowing something can easily be turned into questioning one's overall competence.
I wish we'd be more open about our flaws and knowledge gaps in general. I think we'd all benefit.
Loved your post! I've been feeling the same way (currently feeling crushed by work+master's)... hope to work the courage to break the dam as well.
I need to figure out how to be as open as the author is - it comes across as fricking amazing!
The section on cyberharassment is really troubling, although with the current vitriol on AI I'm not surprised. Do wish the author mentioned the name of the site though, if only so I can avoid it (and not in the Always Sunny "oh no terrible! where?" way)
I was as curious as you were. Turns out there are only so many popular threaded discussion sites in the vein of HN on the Internet, so an educated guess is all it takes.
Without making judgment on the actions of any involved party, I do wonder why the author would choose to bring up this incident and submit it as part of a story to a site where there is a significant overlap in readership.
That incident catalyzed the fear that suppressed my desire to participate online for months. I figured that if I couldn't talk about it now, I might never participate again.
I think Uncle Bobs advice is mostly bad and am afraid to admit it because it’s like a (cargo) cult now.
Here’s a great idea for a good opportunist:
A “Confessions of a Software Developer” website where devs can come in and make anonymous confessions.
Probably already a subreddit for it like r/programminghorror.
It would attract the humble-braggers. ;)
Refreshing to read, I bet it was cathartic to write. I hope your fears don't come true. I think they won't. Many people do genuinely appreciate this kind of honesty, even when directed against them, but it is a gamble.
A good reminder that everything we say/hear/write/read exists in the unseen context of all the things we believe we should not say.
> Remote work sucks
Work sucks in general. Remote work is of course not perfect, but its problems need to be compared against non-remote work problems..
Remote work isn’t for everyone. Their point of view is just as valid as your point of view.
And this is my biggest complaint about arguments about remote working. People turn it into something that’s evidence-based when actually it’s a deeply subjective topic and thus different personality types thrive in different working environments.
People have painted themselves in a corner re: remote work and get wacky in discussions about it. Lots of emo, not much fact.
If you ever feel bad about yourself as a programmer you can go read some Rasmus Lerdorf quotes to cheer up :)
Or work with a random programmer at a random company for a bit. We had to do some audit/estimate for a company with huge tech issues (race conditions causing data corruption, huge slowdowns with just small usage spikes etc) costing them clients/money. The company runs around $50m/year or so selling software to enterprises. Anyway; software backend written with Java/Spring, deployed/updated on EC2 manually, no automated tests (zilch). Frontends with Vaadin. Almost no processes are used, just Jira + tasks and then 'start at the top every morning'. No one knows sql anymore (Hibernate), no one knows html/js (Vaadin) and, even though most people are senior and there since the beginning, no-one has done anything high level on the job in the past 20 years or so. They have just been inside this 'ecosystem' writing code and it works. Old Java with some modern updates just to satisfy the compiler/linter (but not fully understanding why that nonsense is needed). None of the core seniors I interviewed touches computers outside of work, they had 0 tech courses since working there etc. They are all 9-5 code producing robots. I want to bet they can mostly/all be replaced today by Claude Code, of which existence, of course, they are not aware (they did chatgpt but not Codex or Copilot). We have since found so many issues in the code. Yeah, I do feel very much uplifted about my own skills after encounters like this, and these are by no means rare, i would rather say; extremely common.
Unlike OP though, I cannot be as open about these companies as we would definitely not have any clients left after.
My confession is that I actually love torturing people in coding interviews. Sick I know, but these are 6 figure jobs they are applying for.
Remote work is great (for the reasons you gave and more) and saying it "sucks" made me roll my eyes, and it's reductive in the same way as saying office work "sucks." I wouldn't have had a job if in-office was the only option. It certainly didn't suck for me.
Being bad at problem solving with people far away is just another problem you can solve with practice. Same as being bad at problem solving even when help is right next to you.
> made me roll my eyes, and it's reductive in the same way as saying office work "sucks."
Yes, "remote work sucks" is reductive, but I elaborated beyond the heading. Also, I wouldn't disagree with "office work sucks." Remote work simply has its warts, too.
> just another problem you can solve with practice
Perhaps, but practice alone clearly isn't enough. I've been working remotely since 2020 and it hasn't gotten more enjoyable. I would love to solve that problem, though. I read Remote: Office Not Required by Jason Fried in the past, but that was written a long time ago. I've added more recent works (Effective Remote Work by James Stanier and The Async-First Playbook by Sumeet Gayathri Moghe) to my reading list.