**beep ** bop.

  • 0 Posts
  • 21 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle
  • I don’t think your question relates to the language as much as to the platform. The language of choice is somewhat irrelevant and what you care about is what actually happens under the hood.

    For the likes of java and go you want to have some understanding of what runtime does for the memory allocations and how their GCs work. For python you sometimes end up in the spots where you need to understand what limitations the GIL imposes (even more important now that they are trying to get rid of it). When you run C (or C++ or Rust) on the embedded hardware it really helps to understand what exactly bit flipping does in specific registers and what DMA means for how you write your code.

    You don’t really have to know it all. You can absolutely write code without caring about anything of that and I know plenty software engineers that do. Some people write amazing functional things in java without ever questioning what it does to the machines and what resources you need to run it.

    If you start questioning it, that will only expand your understanding. It’s not a lateral move from e.g. C to Rust where you need to learn a lot to write your code in a memory-safe way, it’s a movement deeper into the stack and what you learn there will be applicable to any language you use for this stack.

    Answering your question: I always feel bad about not understanding some low-level concept. I have stacks of MCU reference docs lying around, printed, highlighted; I have archives with sample code, and hand-annotated CMSIS reversing notes. Embedded world is hard because you can’t just know C and be done with it. You have to know the hardware, too.

    Here’s my advice for you. Make notes of things that you learn from people smarter than you. Create a web of those notes and see where your gaps are. Then, work on learning something in those gaps in particular and see if you can make a blog post or something of your own. When you share what you learn you become one of those people with deep understanding that others look up to. There’s always someone struggling with something that you either know or know how to figure it out.






  • By all means, use the publicly available code within the limits its license permits. Always strive to give credit back (I oftentimes add notes to where I took config bits even in my private my-eyes-only repos to have some breadcrumbs).

    Remember that licensing and copyrights are kind of separate things. People own copyright to their work (unless they explicitly give it up), and licenses are the terms on which you can use their copyrighted work.

    Know the basics of the OSS licenses and know which ones you can copy things from verbatim (e.g. don’t touch AGPL code unless you also use AGPL). Generally, I just keep the original license and add a note to my license file saying that e.g. this code is licensed under Apache 2.0, but some parts are MIT.

    It gets somewhat murkier when you use someone’s code and base yours on that. IANAL, and that’s very much the legal territory. If at all possible, just reuse the original copyright and license and then derive your work (given the license allows that).

    Being on the receiving side of this a few times (people using my code verbatim in their projects I stumbled upon) it leaves a bit of a sour taste in the mouth when you see your copyright header replaced with someone else’s completely. Don’t do that. All the three times it happened to me, the other party was quick to remedy the situation, though (2 added the original copyright note back, 1 removed all my code). So just don’t do that. Make a habit to read that dumb tall copyright notice at the top of the file every time and you’ll quickly learn what to expect.














  • The tricky part isn’t the syntax, it’s the domain knowledge. Well, actually it’s syntax, too. Swift has a whole lot of things that aren’t like anything else with sprinkles of Objective-C. Rust turns the common patterns upside down because they make borrow checker sad. But, in the end, what makes you a good engineer is knowing how to apply the tool to solve the problem and that goes well beyond syntax.

    Programming languages are like different kinds of saws: all of them are made to cut things, but there are nuances. Some are replaceable, others can be used for one specific thing. Knowing how to operate a hacksaw gives you some idea how a chainsaw would work even though they are fundamentally different. But tinkle it this way: what are you trying to do? Answering that will tell you which saw you need to use.