!rant

After over 20 years as a Software Engineer, Architect, and Manager, I want to pass along some unsolicited advice to junior developers either because I grew through it, or I've had to deal with developers who behaved poorly:

1) Your ego will hurt you FAR more than your junior coding skills. Nobody expects you to be the best early in your career, so don't act like you are.

2) Working independently is a must. It's okay to ask questions, but ask sparingly. Remember, mid and senior level guys need to focus just as much as you do, so before interrupting them, exhaust your resources (Google, Stack Overflow, books, etc..)

3) Working code != good code. You are an author. Write your code so that it can be read. Accept criticism that may seem trivial such as renaming a variable or method. If someone is suggesting it, it's because they didn't know what it did without further investigation.

4) Ask for peer reviews and LISTEN to the critique. Even after 20+ years, I send my code to more junior developers and often get good corrections sent back. (remember the ego thing from tip #1?) Even if they have no critiques for me, sometimes they will see a technique I used and learn from that. Peer reviews are win-win-win.

5) When in doubt, do NOT BS your way out. Refer to someone who knows, or offer to get back to them. Often times, persons other than engineers will take what you said as gospel. If that later turns out to be wrong, a bunch of people will have to get involved to clean up the expectations.

6) Slow down in order to speed up. Always start a task by thinking about the very high level use cases, then slowly work through your logic to achieve that. Rushing to complete, even for senior engineers, usually means less-than-ideal code that somebody will have to maintain.

7) Write documentation, always! Even if your company doesn't take documentation seriously, other engineers will remember how well documented your code is, and they will appreciate you for it/think of you next time that sweet job opens up.

8) Good code is important, but good impressions are better. I have code that is the most embarrassing crap ever still in production to this day. People don't think of me as "that shitty developer who wrote that ugly ass code that one time a decade ago," They think of me as "that developer who was fun to work with and busted his ass." Because of that, I've never been unemployed for more than a day. It's critical to have a good network and good references.

9) Don't shy away from the unknown. It's easy to hope somebody else picks up that task that you don't understand, but you wont learn it if they do. The daunting, unknown tasks are the most rewarding to complete (and trust me, other devs will notice.)

10) Learning is up to you. I can't tell you the number of engineers I passed on hiring because their answer to what they know about PHP7 was: "Nothing. I haven't learned it yet because my current company is still using PHP5." This is YOUR craft. It's not up to your employer to keep you relevant in the job market, it's up to YOU. You don't always need to be a pro at the latest and greatest, but at least read the changelog. Stay abreast of current technology, security threats, etc...

These are just a few quick tips from my experience. Others may chime in with theirs, and some may dispute mine. I wish you all fruitful careers!

Made poor commit messages for a repo and then found out that we were going to start doing peer reviews at school the next day and that we were going to be assessed by git commit messages.

Rebased at 2 in the morning. Rewrote every commit message.

Did not get assessed by git message.

I am a senior a DevOps engineer who took the production stack down for ~10 minutes today because of a bad code commit. I could use some encouragement! It’s a fierce world of competitive engineers and I wonder why my company doesn’t replace me. The mistake was missed by two other peer reviews... but that doesn’t stop me from feeling this way.

Have you crashed prod? Did your team support you or tear you down?

Me @40 explaining to my parents why am not married yet.
"Well, see, I prefer short commits,
(I mean everybody does)
And then I require at least two peer reviews and approval before pushing.
So she really needs to be perfect to merge"

I started my actual gig as CTO of construction group (Innovation Hub) a year ago. And it was a hell of a ride, implementing kind of a scrum-ban for project management, XP, peer-reviews, a git-flow, git commit message formats, linters, unit testing, integration tests, etc...
And it's the fun part because with the CIO we had to drive the board to do A LOT of changes in their IT/Innovation drive.

But in one year there is a lot of KPI that went up :
* Deployment: When I arrived it took three stressful days to deploy a new version of one application, once a month. Today we do it every week, and it takes three annoying hours.
* We had no test. NOTHING! Today we have 85% code coverage for the unit test, and automatic integration tests run by our CI server every day.
* We had almost no documentation. Today our code is our documentation (it automatically extracted and versioned).
* We had 0 add value in the use of git. With commit messages as "dev", "asked task", inside jokes and a lot of "fix" and "changes". Today we have a useful git, and we even use it to create our deploy changelogs (and it's only mildly annoying!).
* More important, the team is happy! They get their purpose, see betterment in their tech mastery. They started doing conception, applicative architecture, presentations, having fun.

There is still a LOT of bad things we are still working on, and trying to solve (support workflow and betterment). But seeing what they already did, I'm so proud of my TEAM! I'm a fucking asshole, workaholic, "just do it" kind of guy. But they managed to achieve so much. Fucking PROUD!!

Saw a counting variable in code. It was a necessary counting variable, so that is not what this is about.

However, this is a US based company that has a somewhat PC (no cursing) and professional cultural facade.

This variable was called "cnt". How the hell did that one not get caught in peer review? I have gotten dinged for having "possibly offensive" variable names (think Point5Hit though I have never written that as a variable name). It was funny. But I have changed it because that's just lazy.

Add 1 - Remove 2
-implement-

Why did you add this?
Alright - Remove 1 and Add 2.
-implement-

I like what you did with 1 but I'm not sure about what you did here with 2.
-wait...wait...wait...-

Hey, just noticed the way you had 1 and 2 before you started making a bunch of unnecessary changes was better, go back to that.

Peer reviews are awesome!

First rant here

Well thing is that my CS school did have teachers and half the grade was from a product presentation and half on teammates reviews.

My teammates mostly didn't have any idea what SOAP was. That was the theme of the project and we had to make a Webservice which they didn't even understood what it meant.
I spent one day from 8am to 1am trying to explain, in despair I ended up not sleeping, not eating, working 24/7 all the week and collapsing of exhaustion.
I was taken to the hospital, got back home but have lost time and had only implemented 3/4 of the functionalities.
The others (6) only did managed to make a basic GUI I would have to link myself. One of them, the project manager had done testing and lots of good stuff, made a 80pages report but the other 5 were shitty.
They all gave me the worst peer review grade but the manager, they got A I got C (ABCD scale).

How the fuck am I supposed to fucking keep working if these fucking clowns add mandatory peer code review and passing build gating on main repositories (which I completely agree with to be fair) but they don't fucking review pull requests at all? For fuck's sake, am I the only one that reviews them seriously and promptly in this shit ass fuck company? I follow all the recommended guidelines so don't bullshit me with "iT iS nOt FuN tO rEvIeW pUlL rEqUeStS", do your job or just remove yourself from the fucking gating process, you worthless admin ass crust.

And don't get me started on fucking builds that fail randomly because some worthless shit bucket added unstable networking tests as unittests somehow, making your pull request get auto-disapproved by peers upon failure.

I got so many pending pull requests and management won't do fuck all about it because they won't force people to do their job by fear of pushing them around and get HR complaints that I am tempted to simply give up and just start playing videogames.

That moment when a peer who is pretty tough on you during code reviews is super easy on others 😒. Just annoying

Dealing with clients is probably the biggest personal challenge. I'm not much of a people person, and I find it hard to converse with friends and people I've known for years, let alone clients who are looking for answers for why things aren't working, and wanting you to explain exactly (but in simple terms) why a thing that seems simple is so complicated.

Another challenge, which is somewhat related is expressing myself. This again, stems from not being super great or comfortable in conversations, but as a dev, even among other devs, your opinion on things gets asked a lot. For someone who was used to sticking with the status quo and mostly agreeing with things, stuff like peer code reviews, or giving pointers on how to implement something is a big challenge (but I'm improving)

Formal peer code reviews... Reality or Myth?

I have seen it as a myth. Never enough time and budget to implement.

Being a developer for 6+ years in many different stacks, and moving up to a kinda lead level position, has made me feel like I’m not working as much as I was doing before.

Yeah I do code reviews, meetings, tech documentations and peer coding sessions, but still doesn’t give me the feel like I did the work I was supposed to do.

Anyone ever felt this and any tips to overcome?

TLDR, need suggestions for a small team, ALM, or at least Requirements, Issue and test case tracking.

Okay my team needs some advice.

Soo the powers at be a year ago or so decided to move our requirement tracking process, test case and issue tracking from word, excel and Visio. To an ALM.. they choice Siemens Polarion for whatever reason assuming because of team center some divisions use it..

Ohhh and by the way we’ve been all engineering shit perfectly fine with the process we had with word, excel and Visio.. it wasn’t any extra work, because we needed to make those documents regardless, and it’s far easier to write the shit in the raw format than fuck around with the Mouse and all the config fields on some web app.

ANYWAY before anyone asks or suggests a process to match the tool, here’s some back ground info. We are a team of about 10-15. Split between mech, elec, and software with more on mech or elec side.
But regardless, for each project there is only 1 engineer of each concentration working on the project. So one mech, one elec and one software per project/product. Which doesn’t seem like a lot but it works out perfectly actually. (Although that might be a surprise for the most of you)..
ANYWAY... it’s kinda self managed, we have a manger that that directs the project and what features when, during development and pre release.

The issue is we hired a guy for requirements/ Polarion secretary (DevOps) claims to be the expert.. Polarion is taking too long too slow and too much config....

We want to switch, but don’t know what to. We don’t wanna create more work for us. We do peer reviews across the entire team. I think we are Sudo agile /scrum but not structured.

I like jira but it’s not great for true requirements... we get PDFs from oems and converting to word for any ALM sucks.. we use helix QAC for Misra compliance so part of me wants to use helix ALM... Polarion does not support us unless we pay thousands for “support package” I just don’t see the value added. Especially when our “DevOps” secretary is sub par.. plus I don’t believe in DevOps.. no value added for someone who can’t engineer only sudo direct. Hell we almost wanna use our interns for requirements tracking/ record keeping. We as the engineers know what todo and have been doing shit the old way for decades without issues...

Need suggestions for small team per project.. 1softwar 1elec 1mech... but large team over all across many projects.

Sorry for the long rant.. at the bar .. kinda drunk ranting tbh but do need opinions...

Working on a CS370 (Software Engineering) project with 5 people; 2 of which feel like their time is more important than everyone else's so when we all meet as a group to go over presentations, documentation and other things we need to do as a group, they silently sit alone working on bits of code they should have done previously. Then when we can't get docs done and handed in on time, one of the two decides to spam our group chat at 2am when 2 of us are sleeping because we work in the morning, one of us is sleeping because of morning classes and the last one is doing god knows what. Like, I'm sorry. But failure to do your shit on time does not constitute an emergency on my shit. All of our weekly peer reviews reflect on how no matter what we say to these two; they refuse to work as a team.
!rant, more like dev hint
In a team, your time is not more important than team time. You can do things on your time whenever you want; but unless your entire team shares your schedule, team time might be a rare commodity and should be used as such.

I am on my first job, so my boss is the best one I ever had no matter what. But he is a seriously nice person.
He has a daughter he sometimes talks about, he knows the technical stuff, he told me what his visions for the company are (finally moving to git, peer reviews, getting rid of the old Delphi code bases, more Linux support, all the good stuff) and I can work whenever I want.
The only problem: the salary is not that great although developers are in high demand :/