Scala’s downfall is the culture of writing libraries with the most esoteric syntax imaginable. It’s the opposite of Ruby’s “program with pleasure”—-it is “program with maximum cleverness” and “if it doesn’t look like an obscure math equation or symbol soup, it’s probably not idiomatic Scala.” Java’s designers were opposed to operator overloading due to potential for abuse, and did Scala deliver living proof/nightmare scenario of that.
Now I still want operator overloading, because I favor enabling instead of disabling approaches, and I want, for example, new numeric types to have natural syntax that blends in with built-ins, or an equality operator that works consistently. I’ll even settle for += append to strings and collections.
But even Scala standard libraries take operator use to wild extremes. Apparently it’s not enough to use + to append collections, you must use ++. Except Vec you can add with +. There’s ++= and ++=:, and /: and :: and ::: and ?^ and ?^.
Spark Scala interface introduces =!= for inequality comparison. There’s |@| from Cons library. Don’t get me started on Akka. SBT introduces <++=
Surprisingly you can’t override ==, so Spark implements ===. And specs2 testing library implements ====.
I've onboarded experienced and inexperienced developers to fairly big Scala codebases for the best part of a decade and I can't think of a single time symbolic operators were brought up as a source of complexity of confusion. Sbt deprecated <++= 10 years ago.
Agreed. There was a period of time roughly 10-15 years ago where symbolic operators in Scala were very en vogue. That fell out of style in a big way and I haven't encountered symbol soup in a very long time.
Most of the conversations I have with folks about Scala issues these days center around implicits, tooling, and its decline/lack of popularity.
I found it to not at all be confusing once I got used to it—-I find it less confusing and more reliable in practice.
Speaking from 20+ years of Windows use with a local menu bar and 7 years of Linux desktop where I switched to a global menu bar—-it was an instant improvement in quality of life.
I no longer have to hunt for a narrow menu bar strip, just throw the mouse all the way up, and hope to never hunt for it ever again.
Happy to pay 42% higher Patreon fees in exchange for ease of subscription control, visibility, safety and ease of payment with in-app Apple payments.
It’s funny seeing people call 78% operating margin too high, while we all know that software VCs demand 90% margin from their startups, and if it wasn’t Apple, people here would call that an excellent business.
Completely incomparable! It is not a bigger disaster. John Grubber is being an aesthetic stickler -— “comically sad icons”, “indiscriminate transparency” leading to things that are ugly, hard to grab-to-resize rounded window corners, icons in menus “ruining Mac’s signature menu system.”
If you think that adding icons all over the place to menu items RUINS it, I think you’re either in a MacOS “purist stickler” category (which John Gruber is in), or you’re hyping things up for clicks. Because no sane person would call this ruining the menu system.
And new icons “comically sad”? Someone call the whambulance. I saw the new icons, and they are fine. Sure, they are different. But I am not laughing and/or crying about them, and I bet most people don’t find them comically sad either.
Mac is all about premium experiences. Not everyone cares about premium experiences, and that's okay! But those that do aren't going to settle for small degradations such as the ones you mention that in aggregate significantly downgrades the experience.
I hear you on the line of thought that here at work we do work and we keep personal things to ourselves.
I also commend you on your concern for doing things that appear fake, because people indeed are good at spotting fakeness. And I bet they appreciate that you are not acting fake, because that’s often refreshing to see, and they probably value what you have to say more as a result, and quite likely respect you considerably because of that.
For birthdays, wish the employees a happy birthday. You don’t need to get a cake or throw a party (getting cakes for birthdays stops scaling past 10 employees). But everyone should feel a little bit special on their birthday. If you don’t feel that way on your birthday, or you grew up in a family that didn’t celebrate birthdays (e.g. in a Jehovah’s Witness cult), it can be difficult to understand why it matters. But look at it as a technical challenge: can your manager “database” of people hold a birthday field? And can you trigger a smile and a “happy birthday!” greeting on each employee’s birthday? You probably can. The risk for fakeness is quite low (so don’t get a cake and make a big deal out of it), your effort is very low, but the upside for employees is a higher feeling of you caring about them as a person.
Death of a loved one is a really important thing to be aware of. Grief fucks people up and it takes at least a year to come back for it. Grieving employees will need more time and space, and are likely to struggle more. They will come back. And they will stick around more if they felt supported. Offer them to take some time off right away and support them by making sure they can take at least a few days off right away. So if someone tells you of a death of a loved one, you must take note! There’s no good advice to give, so don’t feel pressure to give any advice. Offer condolences and acknowledge that it really sucks (“I’m so sorry for your loss, I can’t imagine how difficult it is right now”). You have to be aware of this as a people manager, because your people.
Religious observances? I’m meh on that one. You can try to develop curiosity about it if the employee talks about it. Ask them why is the observance important to them? If they don’t talk about it, I leave it. For winter time, it’s happy holidays, and done with it.
Okay, a new baby is another one that’s important because your employee will have reduced sleep or be sleep-deprived and have a whole lot of new worries. Be more forgiving with the schedule, let them leave work ad hoc for baby emergencies. You do that, they are much more likely to make up work on their own time as gratitude. Ask them how they feel they are handling the workload—-is there an opportunity to change the type of tasks they are doing? Maybe they are not in a position to be writing deep design docs while they are sleep-deprived. I don’t know, but you can check in when you do your one-on-ones.
Write down their spouse or partner’s names, and write down their children’s names. Keep it in your personal manager file. You probably don’t have people with 5+ children. It’s not a lot. It’s hard to remember. But if the employee feels like they don’t have to say “my son” or “my daughter” or “my wife”, but can just say their names to you and you know who they are, it makes them feel more comfortable and more like a human being. This is another one where it’s hard to be fake—-nobody expects you to remember these things, but it sure feels nicer if you do.
Regarding feeling like you have to fake it till you make it, it’s like picking up a new habit. You have to practice. You will get better at it. It’s part of your job as a manager.
If you find it exhausting, adopt things incrementally. What’s most exhausting? Why is it exhausting? Is it because it’s on top of everything else you’re already doing for 40 hrs a week?
As a manager, you have to care about the people, because they are human beings. It’s a part of your job. You can’t not do your job. If it means you spend less time being technical, so you can spend more time managing people as people and not feel exhausted, then that’s what it means. Push back on your manager to make room to do more people stuff and less technical stuff. You can’t spend 90% of your time being technical and 10% managing, unless you have completely self-directed staff. You’re a person too—-and if you job is to manage, you must make time for it, and if there’s not time for it, then that’s your boss’s problem. If your boss doesn’t think it’s a problem, that’s on you because you haven’t told them.
Managing engineers is like herding cats. They won’t respond to lashing. And cats don’t show that they are sick because they don’t want to show weakness. So if you don’t ask about what’s going on in their personal lives, you’ll be blind to how it’s affecting their work. And because ultimately they get paid to do work, it is therefore in your interest (and company’s interest) to not be blind to how their personal life is impacting their work.
Going back to “fake it till you make it” or brute-forcing until you get better at it—-what you’re not considering is the additional information you will get or increased personal response/appreciation from your people. It might feel like brute force at first, but consider the very real possibility that it can start feeling like a smart thing to do because of the results.
Thank you for the thoughtful reply and all the tips. Truly appreciated.
> I hear you on the line of thought that here at work we do work and we keep personal things to ourselves.
For me that is precisely it. It's how i always worked to avoid possible conflicts, but also because i like to focus on the tasks. At least where i work (and have worked for the past decade) people are somehow personal, and i believe that it is good for them since they seem to like it, but they do find it weird when others aren't like that. I guess that's where culture plays a big role.
> I also commend you on your concern for doing things that appear fake, because people indeed are good at spotting fakeness. And I bet they appreciate that you are not acting fake, because that’s often refreshing to see, and they probably value what you have to say more as a result, and quite likely respect you considerably because of that.
Thanks. Being honest is something i always valued, i really dislike doing things for appearances, and i believe people (including yourself) only grow if you show them the truth. I stopped showing on casual company events/hangouts because i didn't want just to be there as work while not having fun at all. People still expect you to do it tho.
> If you don’t feel that way on your birthday, or you grew up in a family that didn’t celebrate birthdays (e.g. in a Jehovah’s Witness cult), it can be difficult to understand why it matters.
Also that's spot on. My family was never actually religious (although that was the only church they ever went), as far as i remember, and i never correlated the not caring about birthdays with that. But indeed, i forget my own most of the time. The company do provide simple birthday gifts and even a day off, so that is covered i suppose, people do appreciate it. And it was the day my upper manager handed me over my gift that i got called out, because apparently my reaction to it wasn't "human enough" upon receiving a gift, i was so focused in something else that i didn't even thought about a reaction, and took me a second to understand what was the gift for. But the call out was not because of only that.
> If you find it exhausting, adopt things incrementally. What’s most exhausting? Why is it exhausting? Is it because it’s on top of everything else you’re already doing for 40 hrs a week?
Both in and outside of work i do tech related stuff, that ranges from creating scripts for games as a hobby to finding firmware bugs in devices of popular vendors. My whole drive is to solve problems and create things, and make both my life better and improve what (and who) is around me, and for most of the time is also fun. The whole process of people managing is exhausting because, even as a human, i don't understand how to deal with other humans entirely. It's exhausting because that one aspect of my professional life is something i haven't been able to improve despite years trying, as i feel i would need to be somebody else entirely to have a chance on it. It's a "unsolvable problem" that i have to deal day after day, 'punching the nail with my bare hands' as a popular saying goes. I have known lots of engineers who refused management positions because of that same thing, but also a few that accepted because they believed it was a problem they could solve and the offer was too good to pass.
> Push back on your manager to make room to do more people stuff and less technical stuff.
In that aspect i am at fault. Management does give me a lot of room, despite still having technical tasks, but it's up to me to make my team able to solve the tasks that i would have to otherwise. Failing to manage and delegate tasks results in a pile of tasks that i need to finish anyway.
In order to improve my management skills i did many courses, including the Dale Carnegie one (paid by the company). While i don't think those courses are 100% useful, i didn't find them worthless either. You get to see different point of views from people like you, with problems similar to yours, which will make you think different on how you approach them. After those i think i understand the basics, at least in theory, on how to manage people properly but the challenge still in making it natural as to type on a keyboard. You don't look at the keys, you just know where they are and how to do it.
I admit this is way over my head, I am still trying to grok it. This seems to require an existing model to start from—-I am not sure how one would arrive at a model from scratch (I guess start from the same weights on all items?)
I think the point about A/B testing in production to confirm if a new model is working is really important, but quite important is to also do A/B/Control testing, where Control is random (seeded to the context or user) or no recommendations, which helps not only with A vs B, but helps validate that A or B isn’t performing worse than Control. What percentage of traffic (1% or 5%) goes to Control depends on traffic levels, but also requires convincing to run control.
I think one important technique is to pre-aggregate your data on a user-centered or item-centered basis. This can make it much more palatable to collect this data on a massive scale without having to store a log for every event.
Contextual bandit is one technique that attempts to deal with confounding factors and bias from actual recommendations. However, I think there’s a major challenge to scale it to large counts of items.
I think the quality of collected non-click data is also important—-did the user actually scroll down to see the recommendations or were they served but not looked at? Likewise, I think it’s important to add depth to the “views” or “clicks” metric—-if something was clicked, how long did the user spend viewing/interacting with the item? Did they click and immediately go back or did they click and look at it for a while? Did they add the item to cart? Or if we are talking about articles, did they spend time reading it? Item interest can be estimated more closely than just views, clicks and purchases. Of course, we know that purchases (or more generally conversion rates) have a direct business value, but, for example, an add to cart is somewhat of a proxy of purchase probability and can enhance the quality of the data used to train (and thus a higher proxy business value).
It’s probably impractical to train on control interactions only (and also difficult to keep the same user in control group between visits).
The SNIPS normalization technique reminds me of the Mutual Information factor correction when training co-occurrence (or association) models, where Mutual Information rewards items less likely to randomly co-occur.
Re: existing model, for recsys, as long as the product already exists you have some baseline available, even if it's not very good. Anything from "alphabetical order" to "random order" to "most popular" (a reasonable starting point for a lot of cases) is a baseline model.
I agree that a randomized control is extremely valuable, but more as a way to collect unbiased data than a way to validate that you're outperforming random: it's pretty difficult to do worse than random in most recommendation problems. A more palatable way to introduce some randomness is by showing a random item in a specific position with some probability, rather than showing totally random items for a given user/session. This has the advantage of not ruining the experience for an unlucky user when they get a page of things totally unrelated to their interests.
Who remembers Model-Driven Architecture and code generation from UML?
Nothing can replace code, because code is design[1]. Low-code came about as a solution to the insane clickfest of no-code. And what is low-code? It’s code over a boilerplate-free appropriately-high level of abstraction.
This reminds me of the 1st chapter of the Clean Architecture book[2], pages 5 and 6, which shows a chart of engineering staff growing from tens to 1200 and yet the product line count (as a simple estimate of features) asymptotically stops growing, barely growing in lines of code from 300 staff to 1200 staff.
As companies grow and throw more staff at the problem, software architecture is often neglected, dramatically slowing development (due to massive overhead required to implement features).
Some companies decided that the answer is to optimize for hiring lots of junior engineers to write dumbed down code full of boilerplate (e.g. Go).
The hard part is staying on top of the technical (architectural and design) debt to make sure that feature development is efficient. That is the hard job and the true value of a software architect, not writing design documents.
You can also set up arbitrarily complex filtering rules using Sieve, if the built-in rules UI is not sophisticated enough.
reply