massung

As others have mentioned, the real question is what your goal is and whether or not this is a step that gets you closer to realizing it.

If your goal is more leadership and less of an IC role, then what you're proposing is probably a step in the wrong direction.

If your goal is to live in Switzerland, then you just have to ask yourself if you're OK with the drop in order to achieve your goal.

If your goal is to make a change in type of programming being done (e.g. from web front-end to video games) then taking a title (and possibly pay) drop is reasonable. You're going from being an possible authority in a particular domain to someone who is learning. Your current skills and experiences will be highly valuable, you'll learn faster than others, but you'll still have a lot to learn. I don't know how things work in the EU, but here in the States most likely you'll find yourself needing to job hop again in 2-3 years in order to get back to where you originally were (or more).

Answering your actual question, though... I did make that leap in my career and it was worth it. The change I made wasn't so drastic as my example. I had an end goal in mind and came up with a path to get there. It took me a while, but each step was lateral (my current skills were highly applicable) and I learned a lot each step. My path was * video games * video game telemetry (databases and data ETL) * big data at Disney * biotech (where I am now).

TL;DR - what's your goal? Does this change get you closer to realizing it?

This probably isn't the kind of answer you're looking for, but - for me - the answer would be volunteering services and mentoring.

It's not done with the motivation of earning money (otherwise it wouldn't be volunteering). But the network connections made and karma - if you will - that has come back resulting in job offers, people taking the time to teach me new things that ended up resulting in new opportunities, etc. have been numerous.

And while not money, I've made a lot of wealth of friendships in the same way who have helped me through tough times (some financial).

Aside from being a fan of Forth (the programming language) and being quite confused initially, let me say that the site is clean, I like it, and I'm very pleased to see a "Good News" section. :-)

Ignoring the discussion about bundled stuff, this comment actually touches on the most annoying part to me and wondered if anyone here actually has legal experience with this question:

A whole lot of HARDWARE now comes with a license agreement via the firmware/software installed on it and is unusable without it. I recently just bought a Sony soundbar + subwoofer and when I plugged it in was immediately presented on the TV screen with a "you must accept this license to use this device."

However, I have no ability to (easily) see this license agreement prior to purchase and setup. What if I don't want to agree to it? Regardless of the store's return policy, can I return it?

For those looking for the ability to (locally) open and query very large JSON files, Dadroit is great: https://dadroit.com.

It's been a while since I used it last, but it was a life saver for me when working with JSON lines files in S3 and Kafka log dumps.

A side tidbit, IIRC, it was written in Pascal.

Looks like the creator only put in enough for a couple days worth:

    day = Math.floor((new Date() - new Date("Nov 1 2022")) / (1000 * 60 * 60 * 24));

    games = ["NIEDSSLNINARAHIEAETKECGIPEILTZ", "TBERAOTEIBDNATIOEGGUIGUWUNHEOS", "NIEDSSLNINARAHIEAETKECGIPEILTZ", "TBERAOTEIBDNATIOEGGUIGUWUNHEOS"];

    letters = games[day];

    lettersarray = letters.split("");

Neat. The first play through was confusing as it was unclear that I was using letters that would be replaced with new ones. Making that clear would be good.

I'd also suggest that what makes wordle so popular is that it's shareable in a meaningful way without giving away answers.

The share should have your final score as well as colored blocks of all the words made (without the letters) like wordle and put into the clipboard for pasting.

It was fun tho!

This has little to do w/ being a developer vs. being human.

People joke about the programmer in a dark corner plugging away and never talking to others, but that's actually pretty rare. In 20 years I've only worked with a handful of developers who don't want to socialize, collaborate, or solve problems together.

The truth is that people - regardless of discipline - generally all want the same things from their work: to work on something meaningful, to be productive, and to be recognized for that work (both output and input).

That's pretty much it. If - as a leader - you can do those, you're going to generally have rather happy employees.

When it comes to this article, the issue is that there are a lot of people who believe that documentation and effective communication ARE necessary, but that work ISN'T recognized, and (because it isn't recognized) steals time that could be spent being productive doing something that is.

If you want effective communication, documentation, etc. at your workplace, it's incumbent on leadership to create that culture. Nurture it, get better at it themselves, and help those less eloquent to find their [written] voice.

IANAL, but I think not.

I think this because there have been a plethora of tools and libraries over the decades (think Tk, WxWidgets, and similar) that emulate the native look-and-feel of the OS and I believe a company has to defend it's IP/copyrights otherwise it implicitly loses the ability to do so in the future.

See: https://www.varnumlaw.com/insights/enforce-your-intellectual...

Consequently, this is why companies will so often be quick to "attack" random side projects people do targeting their IP (even very old IP). It isn't necessarily out of a malicious desire so much as a legal requirement. If they don't then a "serious" company can follow suit and then they have no ability to fight it.

Edit: to be clear, obviously they _can_ sue.

Absolutely +1 on the exercise. For me it's road biking. I just hop on farm roads and ride for hours listening to Audible, podcasts, or nothing at all and just enjoy the scenery.

Also - and I can't stress this enough - absolutely use your vacation time. And when you do, utterly disconnect from work. Turn "do not disturb" on your phone and other devices and not only don't answer work emails, don't even look at email, slack, etc.

I agree with the comment about doing whatever it is that will relax you. Sometimes that is just binge watching the latest Netflix show. But, if you work from home, I've found that absolutely nothing beats GOING somewhere for your vacation time. I - and friends who also WFH - find that just being at home on vacation can still be emotionally draining. Even a 4 day weekend away from home doing something completely different can be very recharging.

Even if I've come back to work and had to fix things others "broke" because they had to work around me not being there, I was much happier with that than if I did any work during my time away. And it also pointed out to me where documentation and knowledge was lacking or tools could be improved, etc. ;)

This comment may come out wrong, but it is intended as an honest question (at the end) on this topic (whether it be autism or ADHD)...

Speaking only for my self, my own perceptions, and very little knowledge or understanding of what such a diagnosis _actually_ means, I think the biggest "issue" (or misunderstanding) I have is with respect to how it "dumbed-down" to non professionals.

I liken most of the comments I hear - and read (online, in news/articles) - about autism to those of astrology: literally these are traits that describe every last person who has ever lived. It's just a matter of what side of the bed you happened to wake up on that day. For example, I literally just googled "autism symptoms" and the first link is to the CDC, which quickly summarized the following (highlighting a few).

And before I list these, please know I'm not knocking or attempting to belittle the following items as opposed to noting what myself - and likely many, many others - initially think when they hear something phrases like those being written in an article or stated by a "random" parent.

* Avoids or does not keep eye contact - literally so many people I know who just aren't very assertive or are extra shy

* Does not share interests with others - so, only children who grow up learning to play alone?

* Lines up toys or other objects and gets upset when order is changed - I dislike things in my house not being symmetric, so what?

* Plays with toys the same way every time - kids _love_ repetition

* Has obsessive interests - like me and programming at age 6?

* Must follow certain routines - most kids thrive off routine and schedules

Then there's an entire list of things that parents likely should never look at because they're mind will instantly jump to "my kid has autism" and think they should be treated special:

* Delayed <insert whatever skill here> - everyone develop and different rates

* Usually eating/sleeping habits - seriously? as compared to...?

* Constipation - really?

* Lack of fear or more than expected - so pretty much "different than me?"

I'm HONESTLY ASKING what people who have this condition (or parents/siblings of them) would like those of us who only have these dumbed-down snippets to know about them and think about instead? If I can train myself to think of X whenever I hear symptom Y then I think things will be better. But right now, the best I can do is just remind myself "what do I know?" and try and be helpful.

LOL. Fair enough. :-)

I just find that when I read most people discussing "why monads" it usually degrades into code examples and the OP still left asking "yeah? so? I could already do X? what did that do for me?"

Similar to how a C++ programmer trying to tell a C programmer about std::vector might leave the C programmer is just saying "yeah? so? void* works just fine."

I was attempting to steer the discussion in a different direction: about taking what you know and codifying it, which allows you to be sure - at compile and/or runtime - about what's happening.

To take it back to your original question:

> Can someone give me a practical example of when one would want to use a monad?

Others have given good examples. But, I'll try and put it into the context of my reply by making up a contrived example.

Let's say you have a hash map and want to look up a key's value. The function can return the value stored or a default if the key doesn't exist. But, you can't tell the difference between your default value being returned or the same value already existing.

One solution would be to return multiple values, including a boolean indicating whether or not it's the default. But, presumably (since we care in this contrived example), downstream decisions and further data needs to know if the key was present. So, you need to keep passing along both values all the time. After all, per the original reply - any value derived later from the returned value also belongs to the category of "maybe derived from a default value/missing key".

Instead of constantly passing around the value, a flag, and maybe even the missing key, you could return and pass around a struct of those 3 values.

But, now you have a problem: all the existing functions you want to pass your value to don't understand your struct. Additionally, if you want to remain true to the "truism", those functions need to also return your struct, which they don't.

Monads are the pattern created for solving this exact problem. Monads define an interface for...

1. Taking a value and returning your monad type

2. Taking a function (F) and returning a new function that can take your struct, extract the original value from it, pass it to F, and return a new struct with the return value wrapped as well.

From there, you get all the other benefits people have discussed elsewhere in this thread "for free".

Whether you're working with a strongly typed language like Haskell (and using the compiler to keep you honest) or a dynamic language like Python (and keeping yourself honest at runtime), the problem and pattern holds true.

I intentionally picked a goofy, contrived example to stay clear of all the common examples people usually give (futures, IO, errors, option, etc.) to show how you might have a very different use-case that can still benefit.

I believe that most descriptions and blogs about monads completely miss the point.

Monads are a tool. And yes, they can be used for things like having side effects in pure code or allowing for the chaining of functions, but those are just tangential benefits. Fundamentally, monads are just a way to categorize data, and the downstream results of that data. In the end, this gives us the ability to codify what we - as programmers - already know, and therefore depend on.

Consider the following mad-lib:

> Any value computed using the result of ____ must also - by definition - be the result of ____.

Now, let's plug in a simple example with "asynchronous function":

> Any value computed using the result of an asynchronous function must also - by definition - be the result of an asynchronous function.

If I call a function call `httpGet` that returns `Future<Response>` and then I take the response and parse the HTML into a DOM object, I know - as a programmer - that the DOM object is of type `Future<DOM>`. I know this whether or not the programming language I'm using is dynamically typed, supports higher-kinded types, or not.

Whether or not you prefer to live in Haskell land, Go land, Clojure land, or Flatland, monads are just a tool for you - the programmer - to categorize your data and codify (at compile time and/or runtime) what you already know.

Just noting that ~60% of all US hospitals are non-profit hospitals (although you wouldn't know it from the bills). What this means is that people who have no insurance pay significantly reduced prices via payment plans, or pay nothing at all.

To be clear, it's not like the hospital won't attempt to collect payment from them; they will. And some are downright assholes about it and will resort to scare tactics (usually farming the work out to a 3rd party). But, to maintain their tax breaks as a non-profit, etc. they are required to work with - and even forgive - patients who cannot pay.

Note: some hospitals are also assholes with the services they provide. They can't let someone die because they can't pay, but once "stable", then can boot you out.

Below this point is possible misinformation. It's my current understanding, but if someone with more direct knowledge can weigh in, I'd be very appreciative.

The above is where a large chunk of the costs for everyone else comes from. Basically, those who can pay are expected to pay for those who can't.

Where it really hurts is for those people who are - what I'll call - barely middle class. They probably make ~$50k / year and if they have health insurance, it's probably not a great plan: very high deductible and/or max out of pocket. Since they are insured, they will get a much higher bill (initially sent to the insurance company) designed to compensate for everyone else who is getting cheap/free treatment. And, because they insured, legally the hospital doesn't have to reduce the cost or forgive the debt.

First, it's not front-and-center; it's small at and the end. But, for those of you who may wish to do more other than comment:

> My wife and I are creating a charity to help bring awareness to the issue, to help sick children and their families, and to try improve the system in whatever way we can... we can use all the help with can get.

https://sterlingstrong.foundation

--

My daughter - at 7 (she's now 12, okay, and quite happy) - had a week-stay in the hospital with Kawasaki Disease. That was easily the worst week of my life. The cost of just the treatment, without the hospital room charges, etc., was $26,000 per dose, and she needed several rounds (3, IIRC). To make matters worse, she was allergic to the IVIg, which added additional complications and costs.

I'll be honest, I don't begrudge Doctors and nurses for being paid very well. I'm very good at my job and I expect to be well compensated. I also expect to be better compensated than most SWEs. I also expect SWEs who are better than I am to make more than I do.

Nor do I begrudge pharma companies for making some serious bank of some very expensive R&D (without that profit, would we even have a COVID vaccine?).

What does bother me is:

* Not having a say. When you're rushed to an ER, you can't price shop, you aren't thinking about insurance coverage (if you're conscious at all), and you can't refuse treatment if it's between "bankruptcy or death".

* I don't care how much info is out there on the internet. I will never, ever, ever have as much knowledge or experience related to my health care as my Dr. The best I can do is mention things I've read, thumb-in-the-wind, use my spidey senses, ask questions, or get a second opinion. But, at the end of the day, if my doctors say "you need X", they are the expert.

* A lot of prices insane due to (IMO) fallacious thinking. Yes, an MRI costs ~$1M. But, at $1000 per image, that sucker has (most likely) paid for itself in months. And the upkeep there-after is not $1M/year. The cost of a single scan should be a small percent of `upkeep + salary of those involved + modest yearly profit`. And that should be normalized and enforced across the entire country. If your hospital bought a better MRI or pays their employees more or have a better Dr interpreting the results? They charge more, but it's likely +/- $50 to the patient.

* Pharma prices are obviously a bit different. An individual pill may only cost them $2, but the first pill cost $500M. I do believe there should be supply and demand involved, but not in the typical way. I don't think "demand" - for medicine - should be based on need. For example, it should be illegal to price gouge someone who will die without your cure. However, if there are only 1000 people in the country with a particular disease, the "demand" doesn't exist to justify the cost of developing a cure. So, in that case, yes, I can understand charging more.

At the end of the day, I don't know that I want 100% universal coverage in the way Canada and Europe have it. I think what we have sucks, and I do think that coverage for children (say < 18) should be 100% covered. No parent should have to ever weigh the cost of their child's health. But, what the US does have is a system that does encourage doctors to be better, pharma to develop cures, etc. I think we have to be able to come up with something that is the best of both worlds.

Just remember what most of giving notice is about...

Presumably you've made positive connections with your fellow teammates and feel some sympathy for how they may suffer a bit with your departure. You're giving notice so they (and you) can mitigate that suffering. During that time you may not be doing much work, but answering questions, typing up arcane knowledge you have about particular areas, etc.

Not burning bridges. If you hope to every use anyone at your current company as a reference in the future, give decent notice. The last impression you leave is likely what will stick.

In the end, I'd think of it as following the Golden Rule. Even if they don't, if you'd like to work at a company that would provide severance in the event they needed to let you go (basically giving you "notice"), then do the same. The world is what we make it.

I's mostly agree with this.

But I'd note for the OP that "complete rewrites" are not necessarily guaranteed failures. It depends how it's done and what the goals of the rewrite happen to be. The two types of rewrites I've seen be successful:

1. Ship of Theseus rewrites. This is where small modules/segments of code in the project are completely rewritten and integrated back into the whole. This has the advantage of being able to test the new code against existing data constantly, get user feedback, etc. Over time, the entire project has been rewritten, but the benefits (for the cost) have been proven at every step. And you get repeated buy-in from everyone involved from management down to end-users.

2. Massive change of requirements. One may argue (successfully) that this may not actually count as a rewrite as opposed to just being considered a new project. These are usually successful when the project being replaced is notoriously bad/complained about by end-users. But, the same concerns still exist: no benefits are seen until done, potential loss of functionality, new bugs, lost knowledge (read: edge cases not ported), etc.

Ship of Theseus rewrites are successful quiet often. The others... yeah, not so much. It's rare. But, it can happen.

After many years (coming up on 20 now) of interviewing candidates and being interviewed, I've found that programming tests are not indicative at all of candidate success in the job. The only reason to use them is a quick weed-out of resumes, before someone takes time out of their day to do a phone chat. Even then, only for very green/junior candidates.

My absolute favorite thing to do is go over the candidate's work history (or classes/personal projects if a recent grad):

* What project did they enjoy the most?

* What did they work on specifically?

* What trade-offs did they make?

* What were the major risks early on?

* How were those risks mitigated?

* Were there any unmet goals?

* What would they change in hindsight after seeing the project through to completion?

* What parts of the project were the most frustrating (non-technical answers here are great, like frustrations with deadlines, other team members, management, constantly changing goals)?

* What did they walk away having learned?

* How have they applied what they learned to future companies/projects?

It takes a bit longer, but it's so worth it. If you get a good programmer talking about a project they are proud of, you can end up talking for 30-60 minutes easy about every detail, have fun doing it, and learn a lot about them: how they think, how they work, how they work with others, how they work under pressure/deadlines, do they communicate well about problems, whether they'll be a good fit culturally, etc.

Just to be clear for @bitwize, nil is an object like everything else in smalltalk. It's an instance of UndefinedObject. It isn't special in any way and executes any method it understands just like all other objects.

Object>>isNil ^false

UndefinedObject>>isNil ^true

It drops into the debugger if you pass it a message it doesn't understand.

Scott, nice service! Two notes:

1. I don't know if it's the social media kiss of death at work, but I'm getting lots of SSL errors trying to load your site. It's a crap-shoot whether it works or not right now.

2. Seeing this post, I posted this: https://news.ycombinator.com/item?id=27711124. If you don't already (did I miss it?) it might be worth tossing up a page or an item in your FAQ teaching people about how they can go about migrating their email address to another/your service. I don't know how easy/hard it is (hence my AskHN post), but the perception is that it's nigh impossible to do.

My best advice would be on two fronts that mutually benefit each other:

1. Start taking pride in what you do. This isn't just work, but everything. You'll slowly start becoming someone (at work) who doesn't want to demo something "meh" because you'll be embarrassed. If you take pride in your work, everyone else will too, because it'll be good.

2. Realize that what you do isn't for the company; it's for your fellow teammates. They depend on you. If you are late with your work, produce shoddy work, etc. then they can't get their stuff done. They miss time away from their family because they are cleaning up after you or working around your short-comings. You do your best to help them, and in-turn they'll do the same for you.

Both of these will apply to any job you have and any position. Anyway, a strong work ethic is a symptom, not a solution. Do the above and the two things you wanted will fall into place.

The only time the above can be tricky is if you have one of those "thankless" jobs. These are almost always behind-the-scenes people who make everyone else's job possible, but people rarely think about them (think janitors and IT). With those jobs it really pays to be a strong self-motivator and work for a company where those jobs are recognized for the contributions they provide.

I'm just spitballing random thoughts...

Making the "check website" free (forever) should be pretty simple, but that's really only a part of what's valuable. Things that could be add-ons to encourage a subscription once verified that the service is simple, works, and saves time:

* Additional subdomain checks.

* Deep page checks: JS, CSS, images, everything beyond the initial HTML and "yes, I received an OK 200". Make sure the whole page loads.

* Test that intra-site links on the page (e.g. page "/a.html" links to "/b.html") work.

* Report any JS errors on page loads. Also and console.log output and "debug" things like map files, Vue.js/React tools that shouldn't be enabled in production, etc.

* Test with different User-Agents to follow any redirects (e.g. to mobile subdomains) to ensure the site is doing the right thing.

* Use libraries to fully load the page(s) using different browsers and devices, capture them, and show thumbnails/screenshots of the page fully rendered across browsers and devices.

* Provide a REST API so that as part of a CI process someone can call it and have their dev site tested.

* Test REST APIs, logins, analytics, etc. for sites where users can create specific tests that run. Also test correct response codes for expected failures (e.g. access denied).

Anyway, there's likely other services that do similar things. I'm not experienced enough in this area to know all of them, but the above are things that I wish were easier for me - and my team - to test regularly.

Hope some of this helps.

For those who are old enough to have used the original Visual Source Safe, they'll remember that "Get" and "Delete" were right next to each other in the context menu (edit: or at least very close by) of the code tree.

My first week at a game studio, I right-clicked the root of the tree and... yep... chose delete. And it "just worked".

Obviously not just my fault alone, but yeah, that was a pretty rough first week.

To be frank, it's an almost impossible question to answer without specifics. It's a lot like asking "how do I know if my code solution that doesn't work is the completely wrong idea?"

It's quite possible that it is the right idea, and with one minor change the whole thing falls into place and works.

Without the specifics of your service:

* Are you reaching the right market?

* Have you done any analytics (are people hitting your site and immediately bouncing or is no one even going there)?

* Have you tried different pricing schemes? Even 100% free just to start getting real users, real feedback, and word of mouth?

I like to go through my work history and basically cover:

1. What did I actually work on there. I usually pick one thing I'm especially proud of that I can talk in great detail about and answer any and all questions about.

2. What did I wish I could have done and talk about why - at the time - it wasn't. Examples: time constraints, lack of knowledge then that I have now.

3. What did I learn at that company that I was able to immediately apply at the next company I went to?

The first is usually all people get asked about in an interview. But the second and third items are far more important. As a hiring manager, I want to know that someone is capable of noticing trade-offs, weak areas in design, and able to learn and grow.

Also, if you can, talking about the second and third items with respect to non-technical things can also be big bonuses. For example, did you have a problem co-worker that you had a hard time interfacing with, but learned better strategies? Or maybe you did a poor job with time estimates, but recognized why and were able to improve on them? These are all things everyone can relate to.

Back in the day, I think my friends would spend half the night just rolling characters before I even got to start. Still lots of fun, but that in particular was so frustrating.

Re: Code Reviews

Like anything there are good versions and bad versions. I think we've all been through bad code reviews and bad code review processes, so let's skip talking about those. On the other side, here's what good code reviews/processes I've been a part of accomplish:

1. The give the creator of the code the opportunity to rubber-duck. I've found that 80+% of all bugs found in code (before merging) are found by the programmer themself just by talking through what each change is meant to accomplish.

2. The give the reviewer(s) the opportunity to ask very simple questions and questions about how the code change relates to other major systems that the PR creator may not even be aware of. If there are any remaining issues with the change (the last 20%) this is usually where they are found. This isn't about where to put curly braces. If your team cares about that, use auto-formatting tools or something.

3. It gives somebody... ANYBODY... other than the PR creator, some idea of what the code does and why. This is absolutely critical as it spreads the bus factor. When something goes wrong and a programmer is sick, on vacation, or has left the company, it's critical that there be one or more other programmers who can pick up the mantle. They may not have deep knowledge, but they aren't coming into the code blind either.

4. Building on 3, it spreads the architectural knowledge and decision making of the code base among all the programmers. Code reviews shouldn't only be "run" by senior/lead programmers. Senior programmers should be getting reviewed by junior programmers as well. It's not ego or about teaching. It's about realizing we all make mistakes and we all contribute to the same end goal. Over time, everyone becomes aware of the systems at play and what's going on. When they are presented with a task, they have a much deeper understanding of what's involved, they can estimate better, and they are aware of who else to talk to or involve in the process. Junior programmers will get comfortable speaking up in architectural meetings and bring up good points. This is one way they become senior programmers.

> Why have I never seen...

Simply put, limited history/experience. That's not a bad thing. Rediscovery is good, and often coming at things new, with ideas not weighed down by past thinking can allow for breakthroughs.

> ...a stack language that evaluates right-to-left?

APL, J, K, etc.

> ...a stack language that allows parentheses as a sanity check?

Factor. Not really parentheses, but there are stack languages that use the stack notation ( x -- x x ) to verify stack balance and some that even use the stack notation to validate types. Types and stack balance can even be inferred.

> ...a Lisp that can drop nested parentheses when the meaning is clear from context?

REBOL and now Red, et al. But, as @mananaysiempre stated in another comment, the primary use of parentheses in Lisp is due to functions that allow for variable arity.

Last I worked with Nim, the most frustrating aspects of it were how it implemented tuples and multi-threading.

Tuples are really more akin to records, which name their fields. Because of that, I found many things quite difficult to do since I couldn't just return and work with a generic tuple type; read: (int, string) doesn't equal (int, string) because one is forced to name the elements and magically know the names of elements as well from returned tuples.

And multi-threading was just a mishmash of ideas, none seemed "blessed" or really 1.0 worthy (as of 1.0).

Those two issues aside, I really liked Nim when I tried it. Maybe the issues above aren't issues any more and I should take another look?