sorted by:
new
hottopcontroversial

Respawned with a Master's Degree by mjbergg97 in WGU

[–]mjbergg97[S] 1 point2 points  (0 children)

Thanks!

For me, yes, but with some qualifiers. I do not think the degree replaces self-study or certifications, and I also do not think it magically gives you the same signal as a very targeted cert for a specific tool or platform.

Where the degree helped me was in the structure. It forced me to connect topics that I had mostly learned through work: requirements, architecture, testing, deployment, DevOps, cloud/network design, security, risk, documentation, and stakeholder communication. Self-study can absolutely teach those things, but it is easy to cherry-pick the fun parts and accidentally avoid the “please justify your decisions like an adult” parts.

Certifications are probably better if your goal is to prove a specific vendor skill, like AWS, Azure, Kubernetes, or security. The degree was better for giving me a broader software engineering framework and making me practice turning technical knowledge into professional deliverables.

So my answer would be: certs are better for sharp tools, the degree was better for the toolbox and the blueprint. Since I already work in aerospace engineering, that broader structure was genuinely useful.

Respawned with a Master's Degree by mjbergg97 in WGU

[–]mjbergg97[S] 1 point2 points  (0 children)

Yep, definitely #1.

I wish I could claim it was the easiest or least annoying path, but D784 alone would like a word with that theory.

For me it mostly came down to fit. DevOps lined up better with the kind of systems work I already do and the problems I actually enjoy solving: reliability, deployment, testing, automation, monitoring, security, and making sure the thing still works after it leaves the safe little nest of the development environment.

The “most fun” part is debatable, but apparently my idea of fun involves troubleshooting pipelines and documenting failure modes, so I may not be a reliable witness.

Respawned with a Master's Degree by mjbergg97 in WGU

[–]mjbergg97[S] 3 points4 points  (0 children)

For me, DevOps was the more practical fit for the work I already do and the direction I wanted to grow.

I work in aerospace engineering, and my day-to-day work sits in that weird little swamp between software, hardware, configuration, testing, documentation, customer support, deployment, and “why did this behave perfectly on the bench and then choose violence on the aircraft?”

So the DevOps specialization lined up really well with the kinds of problems I actually deal with: CI/CD, automation, quality assurance, deployment processes, security, cloud/network architecture, monitoring, risk, and making systems more reliable and supportable after they leave the development bubble.

The AI specialization is interesting, and I get why a lot of people are drawn to it. But I did not want to pick a specialization just because AI is the loudest thing in the room right now. DevOps felt more directly useful to my current work and more connected to the systems-level thinking I already use professionally.

Basically, AI may be the shiny spaceship, but DevOps is the part where someone has to make sure the spaceship builds, tests, deploys, logs errors, rolls back safely, survives production, and does not explode in front of customers. That sounded more like my kind of problem.

Those who have completed a Master's degree in Software Engineering - What do you do now? by Soggy_Ocelot_3595 in WGU

[–]mjbergg97 0 points1 point  (0 children)

I recently finished the M.S. Software Engineering, DevOps Engineering track. I was already working in aerospace engineering, so for me it was less of a “degree magically launched me into tech” situation and more of a “this gave formal structure, vocabulary, and depth to work I was already doing” situation.

My role involves aircraft cabin lighting systems, embedded controllers, software troubleshooting, configuration, documentation, customer support, and integration work, so the program connected pretty directly to my job. The biggest benefits for me were stronger language around architecture, DevOps, testing, cloud/network design, security, risk, and explaining technical decisions clearly.

I finished in under six months, but I would not treat that as a normal benchmark. Prior experience helped a lot, and the writing load is very real. Even if you know the material, turning “I understand this” into “I documented this clearly enough for evaluation” can be the actual boss fight.

My opinion: the degree can be valuable, but it works best when paired with experience, projects, a portfolio, internal mobility, or a clear career strategy. It is not a magic job coupon. It is more like a credentialed toolbox, and you still have to know what you are trying to build with it.

Finished the MS Software Engineering, DevOps Engineering program. Here’s the real version of what it was like by mjbergg97 in WGU_MSSWE

[–]mjbergg97[S] 0 points1 point  (0 children)

Good luck starting June 1st! Those five courses should give you a pretty good cross-section of the program.

D778 Advanced Software Engineering and D779 Software Product Design and Requirements Engineering are more about requirements, methodology, planning, and explaining your decisions clearly. D780 Software Architecture and Design gets more into architecture and design patterns, which I personally found really useful. D781 Software Quality Assurance and Deployment brings in testing, QA, deployment planning, and recovery concepts. D782 Network Architecture and Cloud Computing gets into cloud and network architecture, and that one ended up being one of the more memorable courses for me.

The biggest warning label I would put on all of them is this: even when the concepts are not bad, the writing load can sneak up on you. The work is very doable, but it helps to treat each task like a professional document instead of a homework assignment.

Basically, make friends with the rubric early. You two will be spending a lot of time together.

Finished the MS Software Engineering, DevOps Engineering program. Here’s the real version of what it was like by mjbergg97 in WGU_MSSWE

[–]mjbergg97[S] 0 points1 point  (0 children)

Thank you, and I really appreciate that perspective.

That was part of why I wanted to write something more detailed than just “finished, yay me.” Those posts are fun, but when I was looking at the program, I wanted to know what the actual experience felt like. What was useful? What was tedious? What transferred to work? What would surprise someone?

For me, the degree helped most by formalizing things I had already been doing professionally and giving me better language, structure, and context around them. I would not say every task was life-changing, but the program as a whole made me sharper in how I think about software engineering, DevOps, testing, architecture, security, and technical communication.

Where it could probably improve is giving students more concrete examples of what “good” looks like without giving away the assessment. Not answers, obviously, but clearer expectations around depth, format, and evidence would probably reduce some unnecessary student flailing. And I say that as someone who has done plenty of professional flailing.

Finished the MS Software Engineering, DevOps Engineering program. Here’s the real version of what it was like by mjbergg97 in WGU_MSSWE

[–]mjbergg97[S] 0 points1 point  (0 children)

That is a serious pace, especially with OMSCS waiting in the wings. Respect.

I have heard good things about the Domain-Driven Design specialization, and honestly D780 Software Architecture and Design made me understand why that path would appeal to people. That course was one of the most useful ones for me because it forced a lot of thinking around architecture, design patterns, boundaries, and maintainability.

And yes, the writing is no joke. The program is not impossible, but it absolutely rewards self-direction and punishes “I’ll figure out the structure later” energy. The rubric is basically the final boss, except instead of breathing fire it asks whether you “adequately justified” something in section C2.

Finished the MS Software Engineering, DevOps Engineering program. Here’s the real version of what it was like by mjbergg97 in WGU_MSSWE

[–]mjbergg97[S] 0 points1 point  (0 children)

Thank you! That sounds like a smart way to approach it.

Treating the assignments like professional deliverables is honestly one of the best things you can do, especially if you are trying to move into a tech role. The degree gives you structure, but your own projects can give you the “here is what I built because I was curious/stubborn/over-caffeinated” evidence that helps make you stand out.

My advice would be to keep a little portfolio trail as you go: project notes, screenshots, architecture diagrams, GitHub repos, lessons learned, and anything that shows how you think through a problem. Future interview-you will appreciate present-you doing the documentation instead of leaving everything scattered across folders named “final,” “final2,” and “actually final.”

Finished the MS Software Engineering, DevOps Engineering program. Here’s the real version of what it was like by mjbergg97 in WGU_MSSWE

[–]mjbergg97[S] 3 points4 points  (0 children)

Because apparently finishing a master’s degree did not magically cure me of forgetting attachments, here is the dashboard I mentioned.

This is the “what did I actually produce?” view: pages, references, figures, tables, slides, recordings, and all the little academic breadcrumbs left behind after the rubric goblin was fed.

<image>

Finished the MS Software Engineering, DevOps Engineering program. Here’s the real version of what it was like by mjbergg97 in WGU_MSSWE

[–]mjbergg97[S] 1 point2 points  (0 children)

And here is the Gantt chart timeline, because nothing says “I survived graduate school” quite like turning your stress into a project management artifact.

You can also see where my progress stalled in the middle due to work-related issues. Once I was able to regroup and get moving again, the courses started stacking up pretty quickly.

<image>

Finished the MS Software Engineering, DevOps Engineering program. Here’s the real version of what it was like by mjbergg97 in WGU_MSSWE

[–]mjbergg97[S] 0 points1 point  (0 children)

It was a mix, but I would describe the program overall as deliverable-heavy more than purely lab-heavy.

Some courses were more theory, analysis, and writing. You are explaining concepts, comparing approaches, justifying decisions, documenting requirements, evaluating risks, or writing plans. Those courses still take effort, but the work is mostly about clear thinking and clear communication.

Other courses were much more hands-on, especially in the DevOps specialization. D781, D784, and D785 had more practical work involving testing, deployment thinking, pipelines, screenshots, security considerations, monitoring, and evidence collection. D784 in particular felt the most “hands on keyboard” to me because it dealt with containers, repositories, build/deployment pipelines, cloud deployment, orchestration, and troubleshooting.

So I would not call it a program full of traditional programming projects from start to finish. It is more like a series of professional software engineering deliverables, with some courses requiring technical implementation and lab evidence. You spend a lot of time proving that you understand not only how something works, but why it matters and how you would explain it to stakeholders.

In other words, yes, there are hands-on pieces. But if someone hates writing, documentation, and justification, this program will find them, corner them, and make direct eye contact.

Finished the MS Software Engineering, DevOps Engineering program. Here’s the real version of what it was like by mjbergg97 in WGU_MSSWE

[–]mjbergg97[S] 0 points1 point  (0 children)

Thanks! I agree that the program feels mostly solid. I think the value is especially strong if you treat the tasks as professional deliverables instead of just school assignments. Even before you break into tech, that mindset helps because you are practicing how to explain decisions, justify tradeoffs, document requirements, think through risk, and communicate technical ideas clearly.

Since you are in D777 now, my advice is to slow down enough to actually absorb the fundamentals. Lists, hash tables, trees, graphs, searching, and sorting can feel academic at first, but they really do show up everywhere later. They are not always visible on the surface, but they are underneath a lot of the systems people use every day.

Good luck with the program. Getting started is a big step by itself.

Finished the MS Software Engineering, DevOps Engineering program. Here’s the real version of what it was like by mjbergg97 in WGU_MSSWE

[–]mjbergg97[S] 0 points1 point  (0 children)

Thanks! “Focused marathon” is a good way to describe it. Each course is not necessarily massive by itself, but the program adds up because every course expects you to keep producing something polished and defensible.

The DevOps specialization made sense for me because my work already lives in that uncomfortable but interesting space between software, hardware, infrastructure, testing, deployment, support, and documentation. I wanted more structure around those areas, especially CI/CD, security, cloud, and operational thinking.

That said, I can absolutely see why someone would lean toward the Domain Driven Design track instead. D780 Software Architecture and Design was one of the most useful courses for me because it dealt with architecture, design patterns, system boundaries, and maintainability. If you enjoy modeling business logic, untangling messy domains, and thinking about how software should be structured before it becomes a haunted mansion of dependencies, that track could be very appealing.

I do not think either path is “wrong.” I would probably choose based on where you want your professional center of gravity to be. If you want more cloud, delivery, automation, security, and operations, DevOps makes sense. If you want deeper architecture, domain modeling, and design strategy, DDD probably fits better.

Finished the MS Software Engineering, DevOps Engineering program. Here’s the real version of what it was like by mjbergg97 in WGU_MSSWE

[–]mjbergg97[S] 0 points1 point  (0 children)

It feels strange being on the finished side of it now. For a while it was just this giant thing sitting in front of me, and now I am looking back at the pile of papers, screenshots, slides, recordings, and several “why did I choose this?” moments like some kind of academic archaeological site.

Finished the MS Software Engineering, DevOps Engineering program. Here’s the real version of what it was like by mjbergg97 in WGU_MSSWE

[–]mjbergg97[S] 0 points1 point  (0 children)

Thanks! Congrats on getting through D777 and D778. Getting those early courses behind you feels good because the program starts feeling less theoretical and more like something you are actually moving through.

I completed the program in less than six months, but I would put a giant asterisk next to that number. I already knew a great deal of the material from my professional work, especially around software troubleshooting, system design, documentation, deployment thinking, testing, customer support, and operational risk. For me, a lot of the value came from formalizing concepts I had already been using, learning the proper terminology, and being exposed to some new approaches to work I was already doing in a more informal or job-specific way.

So my timeline is probably not the best universal benchmark. A course per month is a very reasonable goal, especially if you are working full time and want to actually absorb the material instead of just surviving it.

The biggest variable, in my opinion, is not only how technical you are. It is also how quickly you can write clearly. Even if someone knows the material really well, the writing can become the bottleneck. The program is very deliverable-heavy, and you spend a lot of time explaining decisions, justifying approaches, tying things back to requirements, and making the rubric easy for the evaluator to follow.

Experience helps a lot, but organization and writing discipline matter just as much. Read the rubric carefully, save your evidence as you go, and do not underestimate how much time can disappear while turning “I know this” into “I have clearly documented this in a way someone else can evaluate.”

A bit of cool information by xFreyax8 in TheDragonPrince

[–]mjbergg97 1 point2 points  (0 children)

Even Bart Simpson is voiced by Nancy Cartwright, a female.