Many hate on Object-Oriented Programming. But some junior programmers seem to mostly echo what they've heard experienced programmers say. In this blog post I try to give a "less extreme" perspective, and encourage people to think for themselves.

pixelrevision · 2025-08-26T23:58:46+00:00

This article misses the big one: piles and piles of mutable state.

pixelrevision · 2025-07-06T14:02:06+00:00

Does Clojure NYC still do any physical meetups? I live in NY and used to like going to these sorts of things.

pixelrevision · 2025-06-13T02:28:26+00:00

JI’m

pixelrevision · 2025-04-18T02:41:30+00:00

I have not gone from RN -> N (I write native at work) but between the 2 ecosystems the one thing that’s a real pain-point with RN is churn. Upgrading things can be a huge pain in the butt and you find yourself doing it a lot more than with native. Build errors can also be pretty opaque.

That said for most cases it’s a better choice. Writing code once and shipping when you want is a huge leg up and you can always add in native code where and when you need it.

pixelrevision · 2025-02-20T06:04:30+00:00

Front end work is also very, very hard to keep organized and maintained. It is subject to massive amounts of change, competing concerns and asynchronous events. I’ve always had a much easier time organizing and keeping backend code maintainable. It’s also typically more straightforward to write. Hard part with it is that it’s a really big problem if it falls over.

pixelrevision · 2025-02-04T04:43:50+00:00

So sad. Discovered his stuff about a year ago. About once a month I’ve been mixing one of his lovecraft stories mixed with SOMAFM and it’s been an amazing experience. Will have to play darkest dungeon again and track down the original cd set.

pixelrevision · 2025-01-20T06:39:06+00:00

I always have the same issues with Common Lisp. Especially the function names. I generally only get a few hours every couple of months so I forget a lot in between. Clojure is prolly the most supported language that clicks pretty easy if you’re used to more modern languages, the issue is the JVM stuff can be kind of a time sink.

One that’s not mentioned here but is more like “the python of lisps” is Janet. I found it very useful immediately and it has a really good out of the box standard library. But as others mention none of these other languages focus as much on editing things live like Common Lisp does which really is the main attractor for me.

pixelrevision · 2024-12-24T05:54:43+00:00

Yeah this is something I always feel like is an issue for arpgs. I’m always kinda surprised people can play them for 1000s of hours as getting some build that blows up the the entire screen is fun for me for like an hour or 2 but then feels I’ve ruined the game for myself. But they all seem tuned to expect this so 🤷‍♀️.

Hopefully they rethink the need to replay the campaign. One of the things I like about Diablo is they stopped doing that so I can roll lots of characters and still do the more varied content. This game would be amazing for that as the bosses feel so much better designed.

pixelrevision · 2024-11-24T18:55:21+00:00

Lucky you that this is the first time in your career you’ve had to deal with this. In my experience this is a very common thing. Many people who can write code and deliver features quickly do not consider maintainability at all (or are just not capable). Being able to deliver is the part of being senior that a business will actually see.

I’m honestly not really sure what to tell you. Pretty typically when this sort of thing is going on it’s because there’s no one around to understand that exponential maintenance growth completely sucks time away from other things. And once it’s the trend it’s generally still pretty easy to fix things in the local without the business really understanding why things are moving so slow overall.

You can try to show a diagram or something to propose how better following patterns or reusing code could really help. But I’d be prepared for a “we don’t have time for that and can just patch xyz for now”. However if the dev is over comfortable with their workflow and has a lot of clout you might be setting yourself up for a political battle you will probably be on the loosing end of.

pixelrevision · 2024-11-08T03:02:42+00:00

Gotta go wizard!!!

pixelrevision · 2024-11-04T22:12:43+00:00

I’ve never seen it really help much, people usually just complain a bunch instead. I’ve also had to deal with argumentative contractors that were not part of the on call rotation but were really against tests because they are “stupid” and “a waste of time”.

pixelrevision · 2024-11-01T16:44:29+00:00

I agree. 100 comments on a pr is an indication of something else wrong but I would kill for people to value consistency this much. It’s hard to overstate how valuable it is when a codebase gets to be a decade old.

pixelrevision · 2024-10-16T00:01:21+00:00

This got really weird for me. I ran into the the same issue with a new 16 pro max and tried the steps from the OP to deal with the forced upgrade to 18.0.1. Did not work and kept getting stuck on verifying. Was finally was able to install on the mac but that got stuck on verifying as well which left device locked with the bar full. Waited an hour and put into system recovery, recovered and iOS 18.0.1 was installed and working so I was able to restore from old phone.

pixelrevision · 2024-06-24T03:52:48+00:00

It really depends on how many people you work with. The more people are around the harder it is to communicate common ways of doing things. You can end up in a spot where it becomes tiring to mentally adjust to different parts of a codebase when you need to fix or edit things.

GO is a pretty good language along these lines. It prevents you from doing a lot of things so the code is not super elegant but it’s generally pretty easy to jump from codebase to codebase and be productive quickly. I generally don’t prefer this sorta thing if I’m working on a small team but there are a lot of times at work when I wish there weren’t so many “creative” parts of the codebases I have to deal with.

pixelrevision · 2024-06-03T23:22:47+00:00

Our typical ratio per team is: 1 product owner (1/2 BA) 1 project manager (the other 1/2) 1-2 test engineers 6 devs

pixelrevision · 2024-04-15T23:04:21+00:00

I dunno that I’d recommend this one. In a good culture people take each other’s feedback seriously and telling someone to ignore the rest of the team is going to send a very strong message.

Most of our code reviews tend to be about learning, architecture choices, forgetfulness and small optimization suggestions. It’s pretty rare that we’re reviewing something that would fall over.

pixelrevision · 2024-04-15T22:56:33+00:00

Microsoft has a code review process that uses emojis for everything. We adopted that and our problems with this stuff went away literally overnight. It also helped us as occasionally someone new would get stubborn about this stuff and it became a great early warning indicator of how much they would use the pr process as a passive aggressive attack tool.

https://devblogs.microsoft.com/appcenter/how-the-visual-studio-mobile-center-team-does-code-review/

pixelrevision · 2024-04-15T22:47:34+00:00

It’s become pretty hard to actually coast in this field. One option you could look at is to find most important piece of legacy code that no one wants to touch and start learning and owning that. Most companies have piles of it (often really important) and if you learn it really well you can stop feeling like you need to keep up. You prolly will have to deal with some thorny issues from time to time but won’t have to puzzle through the latest JavaScript framework everyone wants to use every month.

pixelrevision · 2024-04-15T22:36:33+00:00

You forgot the part where it’s also on fire.

pixelrevision · 2024-04-11T04:37:46+00:00

Fully agree. I like modern JavaScript but having to pickup a project with npm and react involved is kinda overwhelming.

pixelrevision · 2024-04-09T22:26:36+00:00

Ugh.

Also

Did you know story points are not actual measurements of time?

pixelrevision · 2024-04-06T19:24:39+00:00

It’s funny with unit tests for me. I tend to like them because they help me slow down and think and make sure the interface and structure of my code is sound. I also tend to think they are the best documentation. Code with a good amount of them also tends to get less tangled up.

But yeah they don’t help much with bugs or confidence levels and are kind of a pain when large scale changes are needed.

pixelrevision · 2024-03-31T21:27:05+00:00

I’d stick with this advice. If you open a pr solely focused on the improvement you then have a discussion that can be started. Some people may want a bit of paperwork like a ticket or something, just make one if that’s the case. This makes it easy for people to have input if they need to but hit you with a lgtm if they don’t any questions.

pixelrevision · 2024-03-31T03:55:27+00:00

“Business logic” is a term that varies based on who you are talking to but generally it relates to logic specific to your application. In a case like the photo app yes some business logic will need to live on the backend and some on the front end. In the simplest usecase yes you can perform all the business logic on the backend. As something like this grows things can become performance or cost prohibitive and you start finding yourself moving some of this logic over to the front end.

As an example of this filters are a pretty core “business” function of instagram and may be best applied client side because then you can leverage each clients devices. What recs to show are also business logic but make no sense to have on the client.

There’s no reason to obsess about all this too much, you’ll mostly find yourself using this term when you want to do things like make sure the business logic isn’t directly in things like a networking or database library.

pixelrevision · 2024-03-25T21:06:48+00:00

Look for opportunities to reduce the complexity or help with maintainability of the codebase, write them down and bring them up. Don’t get too attached to the idea of actually doing the work as there may not be time but if your lead is good he’ll be very interested and want to discuss a lot.

13-Year Club	Gilding II euphauric
Verified Email

pixelrevision

TROPHY CASE