I think the answer is obvious. Start looking for another job NOW. Work is out there, if you can code.
I think the answer is obvious. Start looking for another job NOW. Work is out there, if you can code.
Depends on what metric you are looking and how. A warmed up JVM will run nearly as fast as Go or Rust, but many benchmarks fail to take JVM warmup into account and erroneously show Rust/Go as orders of magnitude faster, which is unfair. That said, it would be nice if warm up wasn’t required. Graalvm helps in that area, but now you have to do something special.
However, JVM startup time is terrible. It’s gotten better and there are ways to deploy a trimmed image, but it’s still not as good as most other solutions unless you go into annoying extra steps.
The JVM is a beast, and it’s very inefficient with memory esp strings.
Fine, don’t believe someone that’s done it before. Google “why you shouldn’t host your own email server” and research before you say anything else.
That’s all fine and dandy until your IP address and/or email address gets blacklisted. Hosting the server is the easy part. Properly dealing with anti-spam measures so you don’t get flagged as a spammer or scammer is the hard part. And before you think that’s unlikely, one of the ways of getting flagged is to run an email service on a consumer ISP network (e.g. comcast).
Helm used to be one such service. They hosted the IP address and smtp gateway, but you hosted the actual email server. They had no data to hand over; it was in your home. Unfortunately, their service went offline last year.
I hate to admit it but I’m all-in on google, for mail, drive, calendar, meet/chat, Android, oauth. It’s all too convenient.
I have one personal account, one per long-term client/employer (w/their service), and one garbage (for sign-ups and low-priority web accounts). I often use the [email protected] pattern for creating special-purpose temporary addresses. We use sendgrid for sending user emails.
You will lose the best candidates with an onerous coding challenge.
Our process, which has been heavily influenced by debate on r/experiencedevs on reddit involves a short phone screen, a 30 MINUTE coding challenge, a tech interview consisting of pair programming, and a non-tech interview with management. Very light.
The coding challenge is a FILTER only. It’s not to evaluate who to hire, but instead it’s to filter who not to continue interviewing.
You learn a lot during pair programming in a short period of time, including personality and team fit. We let them drive and we just watch and discuss. The assignment is to fix a bug, and refactor the code the caused the bug.
I like that you explain the data model near the start, although I think more detail would be better.
I believe it’s much harder to master git without understanding the simple underlying data model. Many tutorials don’t touch on it and instead jump straight into recipes for various workflows. Users can follow those recipes, but don’t really understand what the commands they are using do.
I wouldn’t consider the bugs chatgpt’s fault, per se. The same could happen by blindly copy/pasting from SO or a template Github project. If you are copy/pasting from anywhere, it’s even more important that you have good automated tests with good coverage, and that you take extra time to understand what you pasted.
One of the things I do is generate high level tests first, and then the implementation code. This way I know it works, and I can spend extra time reviewing the test code first to make sure it has the correct goal(s).
Learning is another matter. Personally, ChatGPT has greatly accelerated my learning of libraries and other languages. I’ve also used it to help me grok a block of complex code, and to automatically comment and refactor complex code into something more understandable. But it can also be used as a crutch.
Tbh, I hate both. I wish git recognized an attempt to sync with a parent branch without resulting in either altered history (rebase) or a difficult to view log graph (merge). I also hate that teams have to choose one or the other.
It would be nice if all git graph UIs could easily exclude parent branch merges (with a checkbox). I wrote a shell script that did that, but not everyone used it of course.
I rebase with parent branch until I create a PR. Hopefully, I’ll get reviews quickly and won’t have to sync with the parent branch before merging the PR into the parent. However, if the PR lives longer than I’d like and conflicts occur, I’ll merge from the parent branch into the local feature branch.
The best path depends you how much you like to tinker, your preferences, and your target platform. The learning curve is massive for either, and even after that it will take a lot of plugins and configuration to get close to feature parity of an IDE.
You might consider an IDE plugin at first. For example, there’s a VSCode plugin that integrates actual Neovim as the editor. There’s a Jetbrains (intellij, android studio, webstorm) plugin, IDEAVim, that very closely emulates Vim.
All that said, I use Neovim and prefer it over Emacs. The excellent Lua support in Neovim has eliminated the biggest complaint I had with Vim (vimscript vs LISP). Neovim has LSP support and can communicate with the same language backends that VSCode uses.
No matter what you do, learning Vim keybindings can be very useful as a lot of websites and local apps support it (e.g. gmail, github, less, lazygit).
Look into “Hexagonal Architecture”, similar/synonymous to clean/ports&adapters/onion. As someone else said, combine it with “Repository” pattern.
I use hex arch in front end and back end. It adds a couple of layers, but it makes apps much easier to test and maintain.
Yes, but it’s a very rare event. Maintaining state (form fields) makes it less of an issue. As I said, most deploys are at 4am at extremely low usage (usu zero), and even then a refresh is only needed if the backend has had breaking changes. A severe bug requires a mid-day deploy, but in my experience most severe bug fixes are only a few lines and therefore aren’t a breaking change so don’t require a refresh.
Our way wouldn’t work well if you had 24 hours of heavy load, but most apps I’ve written have been US-only with low nightly usage (HR, K-12 admin, power grid, medical).
Zero downtime deployments can get very complex for heavy usage apps, such as blue-green deployment.
We decided to avoid the complexity with some practical workarounds.
TIL about “@” and git blame -M/-C. Thanks!
Here’s my simple formulas based on how much I would normally make: Short term hourly = Yearly Salary / 1000. Long-term (2+ months) hourly = Yearly salary / 1500.
So, if your salary before being a contractor was $200K, then you would charge $200/hr for short term work. For a 6 month job, you would charge $133/hr
This sounds like vertical slicing (incl bounded contexts), which is my preferred architecture for a monolith. It gives you the flexibility to pivot architecture more easily.
I suggest you look into Evolutionary Architecture, with can help keep vertical slicing
We’ve gone all-in with SSR+FaaS (aka JAMStack) with multiple projects. You get similar benefits to microservices, but without the complexity. However, hosting can be more expensive under high loads.
I found TDD make programming more fun because it results in less debugging. Debugging can be frustrating and depressing when you get stuck.
I’ve found ChatGPT makes coding more fun, as I don’t get stuck as often on hard problems and it can generate boilerplate quick than I can.
Watch videos by Primeagen on Twitch and YT. He’s very high energy. Although successful, He has also struggled with depression, drugs, and ADHD in his past, which might be helpful to you. It’s inspiring.
When learning on my own, I I prefer to learn things that will last decades rather than years or months. Examples: Linux (bash, core utils, containers), CS (algorithms, data structures), compilers, other paradigms (functional, logic, oop), hardware architecture (logic gates, cpu design, assembly), encryption algos, Vim, etc.
Stuff that I think will only last a few years I will learn as needed on the job or at least on the clock.