j_z_reeves's comments

I welcome a coworker refactoring a section of the codebase to make it easier to change in the future. I do not like it when a coworker, new to the project, assumes that a certain way is incorrect. Like, introducing docker and additional tooling when no one asked for it. I especially do not like it when abstractions are unnecessarily forced.

Another perspective, if I am busy building out a feature and I open my source control to several huge PRs containing trivial changes, I groan. Now, not only do I have to respond to these PRs in a timely manner, I have to ensure that the changes are part of a codebase's design roadmap.

Large refactorings should be discussed, agreed upon and expected. Breaking a several thousand line module into a folder containing separate modules is nice and a welcome endeavor. I just don't want to see it as part of a feature PR. Discuss it and create a separate PR.

Also, just because you refactor, doesn't even your refactor is good. You can refactor in a worse off way as well. Your refactor may make the codebase nicer now, but could prevent easy changes later. Your refactor may go against best practices. I have seen this from developers that are on the Dunning–Kruger spectrum. Once again, refactors should be discussed and agreed upon.

As a side note, this seems like a great interview question to determine cultural fit. I do not want to work with a "fred" that doesn't communicate concerns and intentions.

I think it's normal to work 50-60 hours a week if you don't actively track your time. When I was going to the office, I actually worked a lot less. I averaged around 35-40 hours. Now that we all are remote, I find myself working 45-50 hours a week. It's too easy to accidentally go over since I do not have to worry about leaving the office at a particular time due to commuting. However, in general, I feel much more relaxed then before and I do not mind the extra work. I do not let it get out of control since, every hour I work extra, my salary per hour decreases. I like to keep it as high as I can since it makes me feel that my time is worth it.

One thing that bewilders me is the time commitment to writing a blog article. It seems like a lot of these high-profile developers are churning out blog posts. It takes a lot of time to write anything meaningful and coherent. It requires research and experimentation. The time to do so just isn't easy to materialize out of a busy and occupied schedule.

I would love it if developers that wrote blog posts wrote, "Don't worry, if this seems magical, it isn't. I spend weeks figuring it out and writing this all out took several days!"

My advice, to myself and you is, just open textedit/notepad, and start writing! Add a little bit and keep revising until it's publishable. It will take weeks/months but I don't think anyone will care.

This is what I had in mind as well. The difficulty ramps up quickly! I just had to do a couple of these and felt confident enough to start applying to jobs.

I never heard about cheat engine before. Are there similar tools for other platforms? I know you can hook GDB to any running process, but once you're in the process, discovering what is occurring is often pretty difficult.

I'm guessing this is how a lot of the game shark cheats were discovered back in the day.

I was surprised by the counts[$1] = counts[$1] + 1, since I didn't think it would correctly coerce a non-existing value to a 0.

yes that would also work! I forgot about the `-c` argument for uniq.

nice, I finally took the time to read the man pages for awk. And whipped out a script to count the number of errors occurred for a particular day for a postgres log file.

   cat logfile | awk '/ERROR:/ {counts[$1] = counts[$1] + 1}; END { for (day in counts) print day " : " counts[day]}' | sort

I just needed to know how awk programs are structured, the rest is just simple programming!

EDIT: I'm not sure if it's actually correct however...

Working on creating a SaaS app to help and facilitate customer demos. It's not impressive but I have never shipped an actual app or tried monetizing something, so I'll start with this.

Along with creating the app, I'm learning how to design it with figma.

Thanks! I'm creating a sight reading trainer using vexflow right now.

I just checked out pitchy.ninja, it's awesome! I've been struggling doing ear training and singing over the past decade. This will help!

As a side question, do you have any good resources or tips on creating music related applications?

It is definitely good to have a choice between OEM and aftermarket parts. That is important! I am willing to bet that if GE allowed aftermarket replacements, the majority of customers would have still chosen OEM replacement parts.

For example, if my Nintendo Switch controller breaks, I will not even hesitate to get an official Nintendo controller. However, it would be nice to have aftermarket controllers work. However, if for example my IPhone earbuds fail, I would hate to not be able to use spare earbuds I have lying around. If my Macbooks trackpad fails, and I see the choice between using a compatible aftermarket trackpad or a genuine Apple trackpad, I would get a genuine Apple trackpad. That is my choice. Someone else would want a cheaper option, and that is fine.

Now, I could see the angle of wanting to force customers to choose GE replacement parts. Less support. They will be able to diagnose or troubleshoot issues without considering aftermarket compatibility issues. Also, yes, they will have another potential recurring revenue stream!

The MIT Entrepreneur course on EdX also mentioned dominating a beachhead market. Their definition is, "A beachhead market is the place where, once you gain a dominant market share, you will have the strength to attack adjacent markets with different opportunities, building a larger company with each new following" [1].

Nice to see an example of that in real life. Did Buildium eventually target adjacent or new markets?

[1] https://executive.mit.edu/blog/launching-a-successful-start-...

I have noticed that popular repos with "good first issue" labels on issues tend to have those issues claimed fairly quickly. There is real competition in trying to display and assert your coding credentials with open source contributions.

Anecdotally, some issues that are claimed for months do not have corresponding PRs submitted. Question to those that mark labels as "good first issue", have you dealt with flaky contributors?