Biggest hurdle? Probably other people telling me no.

- My parents wouldn't let me go to college to study CS because 'this computer thing is just a fad and you won't be able to make a living off it'. Instead they pulled me out of school early and made me go study automotive so I could be a mechanic like my dad.

- At 22, my boss at my first tech company job heard I was taking Java classes in the evenings. Told me to stop wasting my money because I'd never be a programmer.

- Got a job at a game development company as a document writer. I could code by then. When I was done with my work I'd look for bugs and send the solutions to the programmers so they could submit them. Tech lead found out and flipped out. Said I wasn't allowed to look at the code because I 'hadn't been hired as a programmer'.

Today I'm a senior developer and pretty happy with my career.

When people tell you that you can't do something, that should be all the motivation you need to work your ass off to prove them wrong.

Got my first job!

Probably the MOST complete software book on a very broad subject.

This is book to read for those of you are near college grad, first job in the industry. But to the level of detail and broad coverage this book has I think it’s actually a great book for everyone in the industry almost as a “baseline”

From requirements, project planning, workflow paradigms. Software Architecture design, variable naming, refactoring, testing, releasing the book covers everything, not only high level but also in reference to C.

Why C ...because in the consumer electronics, automotive industry, medical electronics and other industries creating physical products c is the language of choice, no changing that. BUT it’s not a C book... it contains C and goes into dept into C but it’s not a C book, C is more like a vehicle for the book, because there are long established, successful industry’s built around it. Plenty of examples.

When I say it’s the most complete on a broad subject seriously like example the chapter about the C language is not a brief over like many other books, for example 10 pages alone are dedicated to just pointer! Many C books have only a few paragraphs on the subject. This goes on depth.

Other topics, recursion, how to write documentation for your code.

Lots of detail and philosophy of the construction of software.

Even if you are a veteran software engineer you could probably learn a thing or two from the book.

It’s not book that you can finish in weekend, unless you can read and comprehend over 1000 pages.

Very few books cover such a broad topic ALL while still going into great detail on those subtopics. the second part is what lacks in most “broad topic books” ..

Code Complete.. is definitely “Complete”

So the image doesn’t match the rest of my book images because I tried to make an amage to cover of the book, inception style kinda haha 😂

Sorta dev related.
I work at a service desk for an automotive supplier.
We've once hab out entire mobile phone system crash and for whatever reason, it won't let the phones connect, if there are more than 50 phones trying to connect at the same time. Kind of a problem if there are 400+ phones trying to connect.
My colleagues showed me what to do in order to get one phone to connect to our system.
It was basically: enter some invalid data on out webinterface, save, enter the correct data again and safe again.

It was too stupid for me. So i hacked an AutoIt script together in about 15 minutes, and let it run for the next half an hour. Showed it to my colleagues, they were excited and I went and got a coffee.

I'm currently 2 months into a 6 month project for a large automotive client. After being derailed onto a different project a week after I started, I'm back onto the project I was hired for. I asked my manager today for some data from the client so I could move forward. He said "well, we haven't won the contract yet, so they're unwilling to give us the data at this point." Talk about being blindsided.

So we had a guy who spend decade in automotive, flight simulation and stuff. C mostly. Lasted only a month of his probation period. Didn't seem to know about double pointers. Maybe coding standards in automotive even discourage them...

But made me wonder how to judge skills. - I tend do be on the cautious side, as I hadn't really understood inheritance and many basic things when I started. But luckily my first boss believed in me, saw me gnawing through (Well about my 'initiation' that'd be others stories to tell). Well, guy was hired as a 'senior', so they expected bit more. Dunno, still feel a bit strange about it, even if I ranted about his chattering before, coz he also had his heart in the right spot, but maybe it's for the best anyway...

But guess who's taking his place in our team! Drumroll.. Yes, Mr gitmaster is.

Talking with manager about C++ ...

ME: ... and those are the main differences when coming from C03 to C17.

MGR: OK. I think I got it... are these changes those kind of changes that when we know them we can work in any industry if they use C++?

ME: No they are not, sorry. They are like basic enablers to even start considering entering some industries. What you mean are standards. AUTOSAR standard for example is for automotive industry.
The standard requires some level of C++ standard competency.

MGR: Are these standards like plugins for C++...

ME: ? ... no. They specify rules and architecture, conventions and such.

MGR: ... aah. Architecture, I know that word. So in fact they are plugins....like...like...Eclipse IDE has architecture and it can have plugins....right ? ... and you just plugin that AUTOSAR standard to C++ language.

ME: I think you mixing stuff up on multiple levels here. I think we are not ready to talk C++ competency as a strategic decision yet... lets get some basics down first and discuss this stuff in one month.

MGR: ... ?..but, but I mean it can't be that hard. I think I almost got the gist. I just misunderstood at some point.

ME: Sure, sure. No worries...you almost had it *with deep sarcasm*.

Large majority of rants is about incompetent project managers.
No matter where you live the problem stays the same. Most of them have no clue how software is being made and how dev/qa work looks like.
I frankly do not understand this phenomena. I have friends in automotive/constructions industry and theirs managers are engineers too in that field. Why it can't be the same in software development?

Facebook owner Meta Platforms, 2,564 job cuts in Menlo Park, San Francisco, Fremont, Sunnyvale and Burlingame
Google, 1,608 layoffs in Mountain View, Moffett Field, San Bruno and Palo Alto
Salesforce, 1,151 staff cutbacks in San Francisco
Twitter, 900 layoffs in San Francisco and San Jose
Cisco Systems, 673 job cuts in San Jose, Milpitas and San Francisco
Grocery Delivery E-Services (HelloFresh), 611 layoffs in Richmond
Amazon, 524 staffing cuts in Sunnyvale and San Francisco
Intel, 490 job cuts in Santa Clara and San Jose
Rivian Automotive, 448 layoffs in Palo Alto
Lam Research, 400 staffing cuts in Fremont and Livermore

My desk. Not developing, but scheduling production in the automotive industry.

When I work from home, I probably spend less time working, but I do it seriously

When I work in the office I spend most of the time I would not actually work, pretending to work and probably time spent in actual work is much less

But I guess that better performances in work from home, do not feed automotive industry…

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...

Recently many of us may have seen that viral image of a BSOD in a Ford car, saying the vehicle cannot be driven due to an update failure.
I haven't been able to verify the story in established news sources, so I won't be further commenting on it, specifically.
But the prospects of the very concept are quite... concerning.

Deploying updates and patches to software can be reasonably called *the software industry*. We almost have no V0 software in production nowadays, anywhere (except for some types of firmware).
Thus, as car and other devices become more and more reliant on larger software rather than much shorter onboard firmware, infrastructure for online updates becomes mandatory.
And large scale, major updates for deployed software on many different runtime environments can be messy even on the most stable situations and connections (even k8s makes available rolling updates with tests on cloud infrastructure, so the whole thing won't come crashing down).
Thereby, an update mess on automotive-OS software is a given, we just have to wait for it.

When it comes... it will be a mess. Auto manufacturers will adopt a "move fast and break things" approach, because those who don't will appear to be outcompeted by those who deploy lots of shiny things, very often.
It will lead to mass outages on otherwise dependable transportation - private transportation.
Car owners, the demographic that most strongly overlaps with every other powerful demographic, will put significant pressure on governments to do something about it.
Governments (and I might be wrong here) will likely adapt existing recall implementation laws to apply to automotive OS software updates.
That means having to go to the auto shop every time there is a software update.
If Windows may be used as a reference for update frequency, that means several times per day.
A more reasonable expectation would be once per month.
Still completely impossible for large groups of rural car owners.
That means industry instability due to regulation and shifting demographics, and that could as well affect the rest of the software industry (because laws are pesky like that, rules that apply to cars could easily be used to reign in cloud computing software).

Thus... Please, someone tells me I overlooked something or that I am underestimating the adaptability of the powers at play, because it seems like a storm is on the horizon, straight ahead.

Usually this is somehow fluent what is "the worst" advice, since it rather depends on context, and contexts changes.

There is, though, one thing that was bad idea from the start, on so many angles that even now I believe it is actually " the worst " idea you can have : imagine you have a team, you have work to do, and, as usual, there are people there, and people have their goals and opinions. The worst thing you can do there is to engage with politics, either team- or company-wide.

I was specialist from Poland in German automotive branch. Cars, trucks, AI, this kind of stuff. ( It just sounds interesting, trust me )
Small company working as subcontractor.

The first thing I though is something like, why this or that person is going to tell me what to do or why is he allowed to rat me out or talk behind my back... so this guy told me this is how it is around here and you either play it or suck for everyone. So I went with it, if they want to fuck with me, I will fuck with them.

So fast it went House Of Cards kind of way and in the bad way kind of way. Instead of getting progress we were busy doing political stuff, usually law related, like finding each other misconducts, and there were no end to it. As I had most experience I with systems and stuff we were doing, outcome was pretty good for me, but after some time it escalated to such size that atmosphere was unbearable and I was so stressed and tired of this shit I left. It's miracle that management tolerated this so far. People were as toxic as nuclear waste site (or dota/lol players)

So far the conclusion is to sometimes suck it up once in a while or just clear the atmosphere as fast as possible. Otherwise you will wade in shit up to your chin for very, very long and it is not really healthy on the long run...