On one hand, fuuuuck that…but on the ooooother hand…I kind of can’t wait to be able to hack my car to get more features for free like unlocking the hidden extra core or cache on old CPUs.
I mean I don’t give a shit about EULAs, if they put it in the car I bought in gonna fucking use it lol.
This is spot on
You shouldn’t pad your resume with certificates at all.
I view all of them equally negatively in the sense that I don’t care about them at all. When I’m hiring I’m looking at experience, not pieces of paper (certs or degrees). More corporate companies probably do care more though, at least in the automated portion of their hiring funnel.
Though with that said, from anecdotal experience, a lot of certifications tends to be a red flag as I’ve found those to usually be the weakest candidates.
For standard software development jobs I think they’re completely unnecessary, but I could see something like an AWS cert being valued for a dev-ops job though I’ve never hired for dev-ops so I can’t speak from experience there…
Recently built an SFF PC and the only SFX-L power supply in stock with a native 16pin power connector was their Loki model. Luckily they just rebrand Seasonic power supplies who are afaik known to be pretty high quality so hopefully I won’t have any issues with it. But yeah their stuff always seems to have a big price premium they don’t deserve and overboard “gamer aesthetic” that I’m not really into, so I generally stay away from their stuff.
Project lead (or maybe one of them I’m not sure) just left too: https://stgraber.org/2023/07/10/time-to-move-on/
As I’ve told colleagues and upper management, Canonical isn’t the company I excitedly joined back in 2011 and it’s not a company that I would want to join today, therefore it shouldn’t be a company that I keep working for either.
Ouch lol
It could have just said: c++ programming
The second is exactly how I do it. Keeps everything separate so easy to move individual services to another host if needed. Easy to restart a single service without taking them all down. Keeps everything neat and organized (IMO).
The last time I updated my resume, I took a bit of a different approach to formatting it that I think worked really well. Instead of the standard sections, I wrote it in prose where I basically list each job and wrote a couple of short paragraphs describing what I worked on and things like if/when I was promoted (as in some companies I had multiple titles as I was promoted up). Having been on the hiring-people side more often than the getting-hired side, I find it much easier to read than a big list of bullet points and a (IMO useless) "list of technologies I know" section.
To answer your question of where I put it, yes I put it as another "job" in my experience section. So after my startup folded, I was working on one of my personal projects (an iOS app that's in the App Store that I previously worked on as my job as an indie developer and had picked back up). In this case I modernized it to properly support the latest iOS versions and devices and started porting it from Objective-C to Swift.
This worked out great as I had essentially no gap in my resume since I started working on it again right after I stopped working on the startup. So even though I wasn't getting paid, it showed I was working on something at least (and in this case, something on the appropriate level since I was rearchitecting the code).
Here's a part of that section as a reference:
I approached the project as a senior engineer cleaning up and modernizing code written years ago by a junior — who happened to be me. Within a few weeks I was able to fix all of the core issues preventing its use on iOS 14, modernize the UI, and remove all deprecated APIs (some going all the way back to iOS 3).
In addition, I've been working on a major re-engineering of the data model, porting the entire app from outdated Objective-C to modern Swift 5, and beginning to add new user facing features allowed by the new data model.
I also linked to the GitHub page so they could see the work I did.
As for your question about when a project crosses into resume territory, I would argue any non-trivial project is fine. Even if it's a new project you start from scratch, I think as long as it's the type of work your would be doing if you were hired (in my case I was doing architecture work, etc) or even if say I had started a non-trivial project in a new language I didn't know just to learn it (let's say I started a non-trivial Rust project or something) I think it would also be fine. And I don't think it matters if you've finished it, in progress work is fine as long as it's on Github so they can review it. It's really up to you, but I think the point is just to show you continued to work at your "level" and/or continued to learn it's fine.
This is all just my opinion both from having used it successfully in my own resume and from having been part of the hiring process of many developers, but I can at least say I didn't get any negative feedback about it and I did get the job. This was with a full 6 month "gap" after ending my last position.
My Github username is the same as this username so you can see my projects there if you want (the one I'm referencing here is called iSub), and I'm happy to DM you my resume if you want to see it as it contains personal information I'd rather not share publicly like my phone number (though I guess I could redact it and just post a link, this profile isn't exactly meant to be private or I would have used a different username).
Hope that helps!
I feel like you just answered your own question of why people don’t like VB.NET and prefer C#. Per your own words you have two languages that are “just as good” except one of them needs settings adjustments or it’s not as good, and also has “alien” syntax which makes it harder for other developers to work on the code and makes it harder for you to move to other C-style languages (basically every currently popular language).
So if at best they’re “just as good”, then the obvious choice is C# which requires no settings change and has familiar syntax. Especially so if you can work in both just fine.
It’s not just some “god complex” thing, it’s mostly just practicality.
I feel like that last sentence describes all of AWS, not just the documentation lol
I'm glad I saw this comment because I was also about to skip it, but found the article to be a worthwhile read as well. Thanks for sharing it.