rsaarsoo

I on the other hand have never come across a scenario where I run git bisect to find a commit that broke something, discover a small commit as a culprit and wish I had instead found a commit that's hundreds of lines long.

What has happened a whole lot though is the exact opposite.

I feel your pain. I've got similar amount of experience in my own area, I've been part of several successful software projects, and I have several popular open-source projects that I'm maintaining, but it all seemed to not matter a whole lot as I slogged month after month through interviews with rejection after rejection.

All I can say is that perhaps all those places that reject you are not actually the places where you really would like to work.

At one point I managed to get a job at a company which from the outside looked like a really cool place to work in. However all these interviews painted a very different picture of the work that I was actually assigned to do. I felt like I was being paid a senior engineer salary to do the job of a junior engineer. I was utterly bored and I complained that it's too boring and way below my skill level. This ended up getting me fired. Strangely, I've never had so many work-mates expressing to me how sad they are that I'm leaving. Several of them left the company not long after me.

Currently I'm in a happier place. Not getting as big of a salary but having an opportunity to work on a way more interesting software. And how did I land this job... after a single short interview they told me: would you like to start tomorrow?

I find that take-home assignments are very one-sided form of an interview:

- The candidate needs to do lots of work while the company gets away with little to none. - The candidate never knows what exactly the other side will be looking for, so the only way is to put in more work. Like when the assignment didn't ask for tests, they might still be expecting them. - The candidate usually gets no feedback about the work he did. More importantly he usually doesn't get a chance to defend his solution. It's either great or garbage. - While the company can learn something about the candidate, the candidate will learn nothing about the company by doing the assignment.

I get a feeling that it's more of an art project. The voice-over is over-the-top artificial, reminding Stephen Hawking. The demonstrations of the objects are well executed, but content/education-wise on the level of it's so bad that it might actually be good. And of course, the obsolescence of several of these things is very questionable, let alone being able to accurately identify a year since something became obsolete.

It's like saying you should not need to know about ancient Greece history to participate in marathon running. And the truth is, you don't. You can easily learn the present meaning of a word without fully understanding its etymology.

There are countless words and idioms that will make no sense when you're not familiar with them. You could consider these annoying, or you could consider these the interesting parts of a language.

I for one very much like words with interesting history.

> what's wrong with squash-merges?

In theory I don't mind them. In practice I've found that I more often encounter a scenario where I wish a change had been split to smaller commits rather than the scenario where there were too many commits to go through.

Anyway... I intended my example as an explicitly anecdotal evidence to counter the seemingly absurd suggestion of using Git without ever using merge. Feels like going back to subversion or CVS.

I'm confused... What's wrong with merge?

For all I know, I once joined a company where the policy was to only do squash-merges. I left from there at the brink of mental breakdown.

> [programming] should be an iterative, interactive process that anyone can do. It should be more like painting...

You mean like taking years of rigurous practice to master, requirering specialized equipment and expensive materials plus an education in color theory, composition and art history :)

At the same time in Japan: parents are not pleased when the toddler they sent to do shopping forgets to buy some of the requested items.

https://slate.com/business/2022/04/old-enough-netflix-do-jap...

If you ask for it... I've been hunting for a job for more than a year now. Well, perhaps not hunting as I haven't sent out nearly as much resumes during that time as the author of this story. Though when I do apply, I usually also get to an interview.

The interviewing causes a lot of stress to me. Even though I have never failed a coding interview, I utterly hate doing these. (Thankfully I've never had any hard leetcode problems thrown at me - I would have failed miserably.) I have also been a lot on the other side of the table, though I found even that to be a big source of stress to me. I personally believe these coding tasks are only good for filtering out the bad candidates - you can't use them to find great candidates. The last big company I worked at gradually steered towards harder and harder coding problems, until one day I just pulled out of the interviewing process as I felt that I personally would no more get hired.

I wish more companies would be more flexible in their interviewing process. Like, I have several open source projects which mostly revolve around various forms of static code analysis - why do I need to prove that I can write fizzbuzz?

Recently I had a pretty nice coding interview where the main task was not about me writing code, but instead reading the code that a junior developer had written and helping him sort out why the code doesn't work and how to improve it. This was the most real-work-like task I've experienced, I even found myself enjoying it.

Most of the rejections I've had have been along the lines of: "While we find your technical skills excellent, you don't really look that motivated / we think we might not have the right kind of challenge for you."

So, I'm in a bit of a dilemma. If I would strive to send out more resumes, most of these jobs are likely something that I'm not overly excited about, and so I will get rejected because I don't look committed enough. But if I try to look for a dream job, then that will likely never happen. I feel like I'm doomed either way.

During this whole job search I did get one offer, but I rejected it, as I heard rumors about the owners of the company being complete assholes. (Like monitoring workers through security cameras to make sure they're working at their desks.)

Thankfully I've had enough savings from my previous employments and I tend to live a fairly cheap life. Nevertheless, my savings are starting to run low now, which adds pressure to finally find a job. Well, I still have the option of selling my second house (so I'm still far from being financially ruined).

I think there are pros and cons to both approaches:

- Explicitly spelling out the column names has the advantage that you can search your code base for that name and see where it's used.

- When declaring a view which filters the rows in a table, using SELECT * would simplify maintenance, as you wouldn't need to update the view when new columns get added to the table.

You seem to assume, that one can know what the impact of one's actions will be. That's basically asking for the ability to predict the future.

I don't want to imply that the outcomes don't matter. But at least I prefer living in a justice system where planned murder and fatal accident are not considered as equal offences, although outcomes might be the same.

I've got multiple >1000 star projects on GitHub, and I feel like it hardly matters at all. I'm still being asked to do lots of trivial coding exercises during the interviews. A large percentage of code I've ever written is out there in the open, but somehow it's still not enough to verify that I'm able to reverse a string.

Thankfully, where I live, most companies don't really ask for hard-core algorithm questions - if they did, I would never get a job, as I really suck at these.

From another article[1] about this lawsuit, the Sonos side comments:

> "We believe that most people involved in wireless home audio today infringe on our patents in one way or the other."

So, either:

- most people are stealing their technology, or

- most people have come up with the same solution independently.

For some reason the second case seems more likely to me. Unfortunately for the patent law it doesn't matter if you invent something independently - you're still infringing.[2]

[1]: https://www.theverge.com/2020/9/29/21492671/sonos-google-pat...

[2]: https://www.patentprogress.org/2019/08/23/protecting-invento...

I consider dogs to be pretty fast :)

- There are high quality packages in every language.

- Likewise with mature frameworks.

- All mainstream languages have pretty good OOP features nowadays.

Thankfully yes, there is no concurrency.

As a former Emacs fan, I think Atom is actually the best modern alternative to Emacs.

I just recently looked at my old .emacs file to discover that the majority of code in there was to get the features that come out of the box with Atom. Of course Emacs does allow you to configure and program way more than Atom, but the downside is that you have to do it because the defaults come from computer history museum - it's great fun though if you like to learn about the history of the field.

I've been pleasantly surprised just how easy it is to extend Atom. It invites you to configure it, with very approachable docs and built-in tooling, but it doesn't force you to.