kovac

My two pennies worth:

1. Test your code. I'm a senior engineer and the only way I know how to make sure my code works is by testing it. I use unit tests for this. If you don't like unit tests, find some way that works for you.

2. Try to get someone to review your work. When I'm working on something thats completely new, I ask someone I know and respect to review it and indicate which parts I'm unsure about.

3. First few months you may have to work harder. When I join a new team, despite being a senior engineer I spend time outside of work going through references to refresh/learn things so that questions I may end up asking will not be totally off the wall. After the first few months this becomes less of a problem until perhaps the next new thing comes up.

As for the mistakes you made, specially that QA/prod stuff don't worry too much about that. It's not only your fault. It's seniors job to create a working environment that's safe. On the teams I join, specially after I become a senior there, I push for safety measures whenever someone screws up unless it's deliberate or gross negligence. The fact that you feel bad about it shows that you did your best. I have seen once one of the most talented devops engineers brought a prod server down instead of staging because he is too quick on the terminal with many terminals open in his terminal multiplxer. Once a very talented db admin dropped an important table by mistake fortunately in dev and had backups. Things happen, and leaders/seniors should try their best to secure the environment.

Your job right now is to broaden/deepen your knowledge, ask intelligent questions, test your work before submission and keep calm and carry on.

Or click on the link to the source and see for yourself.

It isn't elitism. It's competence. A system designed by competent users for competent users are going to be different from one made for general masses. There's nothing elitist about that.

There's no reason for a terminal emulator to connect to the internet or collect telemetry opt-in or not. None whatsoever.

This is not what I gathered from the documentary "Four Horsemen". Seems like actual banks are printing money out of thin air?

For laypeople self-hosting is out of the question for now. I'd say the more immediate problem is that even for competent engineers this is a difficult task with all the artificial restrictions put in place in the name of security, anti-fraud, etc.

It depends on which department you take math course in. Any course offered in a math department, even statistics and probability will be treated formally there because that's what mathematics is. What you probably need is to take math courses from an applied mathematics department like physics or engineering.

But math is a broad field so you're going to have to pick specific courses. For example, partial differential equations are quite common. But if you learn it in a math department it'll have proofs and full rigour just like a course in set theory. While some techniques for solving them will be covered, we mostly study the underlying mathematical structures, why certain techniques work, etc. If you take it in a physics department they'll teach you techniques and numerical methods to solve a certain class of problems like heat equations or fluid dynamics. But learning through direct applications will inevitably limit you to those techniques while learning things in full generality tends to make it easier to pick up specific techniques when needed.

I might look into active, high profile opensource projects to learn a thing or two from there. I think for this to work, planning needs to be very precise: as a team you know what you are going to do, devs need to be very good at what they do and enjoy what they are doing. This is often difficult for companies as there are many things that need to be done asap, projects/teams often being managed by non-tech or non-experts.

I've worked part time for a startup remotely across timezones. I personally credit the technical lead for the most part for its success. Then, the chemistry within the team was really good. When someone says something others tend to get it. And the planning. The tech lead sets up the goals for the quarter and push back on distractions from the business side except on rare occasions. The management was also very competent, they seemed to listen to the engineers.

Even if it's paid, you should back them up really.

If it helps,there's an extension called ublacklist that you can blacklist results. I use this to permanently blacklist those sites with garbage.

Mike Tyson, Evander Holy field, I'd imagine there'd be a lot of boxers.

Not sure if it's me, but I feel like Stack Overflow has also started going mad with cookie acceptance requests lately with the default option is set to accept all cookies. It's fucking annoying.

But not all languages emit the same machine code. And I think performance is more sensitive to memory access than machine instructions, so I don't think this point is true.

This is what I used to think about JIT as well. That JIT would have more information than a static compiler to optimise the code better. However, it seems to me that most of the performance depends on how well we can exploit the cache lines and how many fewer instructions the cpu has to execute to get the job done. JIT could perhaps improve on the latter but in many cases it seems to me that it's generally very hard to be cache aware when programming in Java not to mention every user-defined type is allocated on heap. So, I feel like it's quite unlikely that there can be Java programs that outperform C and even then that it can't in principle be done better in C.

Considering that package mgmt is a well solved problem, rewriting these tools for that in return for slow, bloated alternative sounds like a huge tradeoff to me. Fun and learning on the other hand, sure.

Web browsers are one of the most poorly designed applications in existence. It's not surprising that such complex applications trying to do everything possible have vulnerabilities. But in no way that should serve as a benchmark for C as being inherently unsafe when far more important systems like databases, operating systems, system libraries are written in c just fine. Most of the common vulnerabilities in general are due to unnecessary complexity of systems that lend themselves to poor programming practices, configuration errors, low calibre programmers, etc (OWASP list for example). Memory safety vulnerabilities tend to just get more attention since they are in critical parts of a system, hard to exploit and so attracts highly sophisticated exploits that affect us at a nation state or industry level. If these systems were written in high languages by those high level developers, I'd go nowhere near any computer system.

For those wondering/asserting if the author is an expert in neuroscience, she is actually a psychologist by training.

I'm personally very skeptical about anything psychologists say. I would not take any of this by face value without validating them against real neuroscience research or consulting neuroscientists. Psychologists love to say stuff helter-skelter and make them sound like real science.

[https://www.affective-science.org/lisa-feldman-barrett.shtml]

Logicians study this I think in computability theory. It's a hard problem.

https://en.m.wikipedia.org/wiki/Computably_enumerable.

I like this man. I think the only thing we'll look back on is, considering how those who came before us delivered so much with so little (compute power, parallism, safety, tooling), how we fell so far from grace and fuck things right into the ground with slow, unsafe, useless piles of garbage that don't even perform their primary duties well other than collect data.

Looking at the mass of crappy software all around us, I'm not surprised.

A little off topic, but which gopher server (and any management tools? ) do you use for hosting? I'm in the process of setting up one and trying different ones out but haven't settled on one yet.

Isn't keeping 3rd party stuff like TLS out of the core protocol a good thing? Regarding breaking existing clients in a catastrophic way, I think the server could send an error response to the client that don't support TLS (which is defined in the protocol so the clients should understand the error) if it doesn't want to serve some content without encryption or serve content over port 70 over plain text otherwise? I don't see why old clients are a show stopper there.

Thanks for your points. I agree on the TLS, struck me as odd too. Feel like a gopher(s) would be a nice addition.

I'm not a protocol expert. I understand why one would not want to use a subset of HTTP, but why not use the existing, lighter weight gopher protocol instead and implement a server and client that supports TLS for gopher instead? Because TLS being baked into it seems to be the only technical difference between the two protocols.

There's gopher where there is still quite a number of interesting posts. There's also a more recent network called gemini which is gaining in popularity.

Go really? Last I checked its impossible to write an ORM in go, didn't even have a way to do dynamic routing that I had to implement my own router using a trie. Please.

I did. I tried Rider and continued to use VS when I was programming on Windows. On Linux I use Rider (though I'm mostly off. Net stuff now). Reason for using VS is because I like it's UI (like the colour scheme more) and I think there are at times issues with resolving dependency issues like nuget stuff (which is what my colleague told me who is a fulltime rider user but fires up VS rarely to resolve them). I haven't tried things like parallel stack watches, debugging dlls and remote debugging. I just liked these things the way they are in VS. Though I'd rank Rider higher than VS since it runs on Linux.

I'm a software engineer with a pure mathematics degree. I can't speak for the "elite underproduction" bit but the rest of it pretty well covers my case.

This right here is the kind of company any self-respecting engineer shouldn't join unless they are transparent about the fact that they have issues with their processes/don't have people to deal with these issues that they need your help.

If they have a whole arsenal of project managers, architects, product managers, engineering managers, business/product analysts and still give this kind of lousy excuse, I'd probably stay away. Chances are they don't have any real expertise in the domain they are working in.

And btw, requirement gathering and writing technical specifications are taught in school.

Thanks! It's very useful!