So do I! In fact I searched for Powell this morning, after lazily taking down my 1990 Best American Short Stories collection, which was where I first encountered “Typical” and his unique voice.
Totally agree. I would also like to add that, as a non-native, pretty fluent Mandarin speaker, it is pretty hard to chitchat with Chinese colleagues, especially when it is a big group and they come from different parts of China.
> If it seems daunting remember that it’s something even the dumbest two year olds are able to figure out how to do, so you could probably figure it out
Language acquisition skills are normally way better in early childhood.
> I'll never catch up to people that started in their early 20s, but I hope I can figure out how to climb the ladde as quickly as possible.
I was in a similar position a couple years ago. You don't need to catch up. Just pick a certain direction, i.e. frontend, backend, embedded, devops and stick to it. Once you got a certain years in the industry, it is easy to find better paying jobs and it is way easier to get hired.
If you enter any game studio nowadays, you're very likely to see Dear ImGui - it's pretty ubiquitous, and just flexible enough for programmers to make nice debug views for any purpose. It's nice in that you won't have to learn another UI kit when switching studios.
Wow. The paper on NLP I'm presenting soon includes software that I built using the python fork, dearpygui. I had no idea that dear imgui was so popular.
It seems to me to be super high quality of a GUI library.
I noticed that too. I wonder if the creator has ever seen a dime of Rockstar's GTA money. Looks like no[1], but at least there are a few other AAA developers there.
Sidebar: if I wanted to eventually transition from Android dev to C++ game dev, is my time building C++ ImGui tools a comparable experience, or is game dev a truly different beast? Curious for some opinions :)
The reason I like mobile and small desktop applications is partially for the tight cycles of build/test/fix/ship. Even writing it out now, the experience of working on any game of even moderate complexity must be entirely different, right?
Having a tight dev loop is important for complex games too — when you press F5, you build the whole game. Sometimes you even build the engine and all dependencies. Shipping usually follows a slower patch schedule since you need to pass certification etc.
If you work on a game, building ImGui tools isn’t a primary concern, it’s what you do to be able to easily test your stuff.
Yes, you can actually. I haven't done this myself, but there are defconfigs for mmu less devices (stm32f4 series for instance). You need some more RAM though, but most evaluation kits don't provide this. Have a look here: https://elinux.org/STM32
I'm planning to give this a spin on an EVK that I got from work if I find the time.
Linux? yes. Popular distro? not really. Lack of MMU means that all the processes (and shared objects) use the same memory space, so unless you have some way of randomizing where things go (like SELinux), two processes will step on each other's data (MPU will not trigger segfault, as both are allowed to r/w same addr - IIUC). But even when using randomizing, you're playing russian rulette.
drivers, as you said, for filesystems for instance,
syscalls available that we know and love :),
somewhat easier deployment (elf instead of raw bin),
other abstractions that linux provides,
multiprocessing (if done carefully),
real multithreading,
Most things that you state are not culture related. If communication is really troublesome, I understand that you would leave such a place. Better tooling and programming guidelines are things you can introduce. Especially if it is a small team. That's maybe why they hired you in the first place.
Do you have any tips on how to improve in the embedded domain? I've got some professional experience, mostly doing embedded application (MMU-less) development. I'm looking into linux driver development, but it feels a bit above my skill level.
If you want to improve, look at an open source project with a lot of momentum, and learn from what people are doing there.
I'm actively involved with Zephyr RTOS, for example, which is backed by the Linux Foundation and has people working on it full time from almost all the major MCU manufacturers. The development tends to correlate closely to Linux kernel as a model, and a lot of the key members were/are Linux kernel contribs, so skills learning with Zephyr can help you move to Linux dev later if you're new to it.
There is a non-trivial learning curve with Zephyr (device tree, KConfig, etc.), but it has more momentum than any RTOS I've seen in my career, and it has a very helpful community, while keeping the technical bar high.
If you prove your worth there, it's also an avenue that can possible even lead to job opportunities, which I've seen and benefited from myself.
That may or may not be of use, but if you want to improve in the embedded space, getting involved with something like Zephyr is some of the best use of limited time in my opinion to learn from some of the better embedded engineers working in the open.
The number of PRs and committers is what boggles my mind ... it's an endless stream, which is highly unusual for an embedded project. This is where the momentum and technical investment is happening today for open source embedded, IMHO.
> I'm looking into linux driver development, but it feels a bit above my skill level.
Same here. I managed to reverse engineer some of my laptop's USB functions and write Linux drivers for them. That little driver was the most fulfilling software development project I have ever made. Tried the ACPI and I2C stuff but couldn't figure it out. I really want to learn it all but I don't even know where to start...
