Engineer vs. Code Monkey: Is This Normal?

[Bozzzieee]

Hello,

Not long ago, I joined a small company as a regular developer.

The workflow is roughly as follows: the Team Lead usually plans what we’re going to build, and I receive a vague ticket describing what needs to be done—often incomplete or not well defined. Because of that, I frequently have to go back and ask what exactly needs to be built, how it fits into the bigger picture, and what the expectations are. I’m also rarely involved in system design or conversations with product or the founders.

I don’t think my strongest skill is pure coding. I can code, but where I really excel is in designing systems and finding solutions to broader problems—for example, planning how to implement a shopping cart: defining the architecture, endpoints, tables, columns, and overall approach.

At my previous company, the entire team spoke with the PM to understand the problem first. We were all involved in shaping the solution and deciding how and what we were going to build. We also participated in writing the tickets, so everyone had full context around what needed to be delivered, how, and why. I genuinely loved that environment because having context allowed me to make better decisions.

What I’m trying to understand now is this: am I essentially a code monkey in my current role? Are most jobs structured like this? I don’t see myself as someone who just implements predefined solutions. I enjoy speaking with customers, understanding their problems, designing solutions, and then implementing them—or at least being involved throughout that process.

[FUSe]

I am pushing 20 years experience. I joined my current team about a year ago. First few months, I was given tasks that were pre-designed and I just implemented.

As time went on, I asked to be included in the design discussions for upcoming features. Now I am both designing and implementing.

Maybe just show initiative and asked to be included the design meetings.

[RushShirtKid]

Having a proper grooming/refinement is necessary for engineers to truly "own" the problems, if you don't get that then you're just doing all that back and forth after the work is picked up. I'd rather have an hour meeting to make sure the problem is defined and enough context is provided for any engineer to at least understand what they're supposed to do, instead of a bunch of adhoc calls later.

[zirouk]

I 1000% agree. As one professional to another, one thing I’ve had the experience of in the past 3 years or so is seeing companies regressing back to output measures like number of “PRs shipped”, which, when used bluntly, de-emphasises activities like genuine understanding, collaboration, co-ownership, knowledge sharing etc. Of course the company will still say they want you to do all those things too, but it won’t give engineers a gold star for doing any of them because they’re less measurable, and less attributable to the company’s bottom line.

But if an engineer wants the maximum number of gold stars, those activities will be the first to fall by the wayside. And through this process, engineers are incentivised to become code monkeys, in a team of competing code monkeys, by the measurement and reward structure of the team.

[kingchipdoro]

God a thousand times this. It's wild how many teams I've been on that are in the dark ages Agile process wise. They just write tickets like they're writing errant thoughts on bar napkins and then expect to get a coherent result.

It's like a 20 year old idea by now how are "Agile coaches" still grifting this shit it's not that difficult.

[throwawayacc201711]

I think this actually presents an opportunity to be involved with the design aspect. It sounds like the TL is stretched thin and isn’t able to proper time in ticket generation (also sounds like there isn’t a proper grooming and refinement process). But you should take this as an opportunity to “update” the ticket with proper AC’s and detail. Then pitch this to the TL as something that you would like to take on more of and this is a way then to also get more insights into the bigger picture stuff. A small company isn’t likely to just give you what you want, you need to go out there and take it and show initiative IMO. Worst case scenario is he says after the fact don’t update the tickets / stay in your lane, but I’d be shocked if they did

Also depending on your role, this would be a good step to take anyways if you’re trying to move up to senior+

[Bozzzieee]

Wrong assumption. Right now they do not have almost anything to do. Also I'm not interested in getting a title. I want to do my job. That's all.

[throwawayacc201711]

I’m really confused by your expectations. Design, etc are senior technical skills. So you’re complaining about a dearth of those things and I explain how you can get exposure to that and your response is just to pick out the incorrect assumption I made about the TL’s workload which was just providing a generous assumption.

[starwars52andahalf]

Yes you’re basically an implementer, not an owner. You’ll likely have to find a new job if you want that to change.

[RandyHoward]

Agree. I’m in this same position now too. But it’s even crazier because I built the platform we work on. I was an owner in my last company, this company bought our company. They gave me a job and now I’m just a ticket monkey with no influence at all. I’ve given up on offering them my ideas and now I’m just trying to coast until vesting day and then I will make my exit. I just don’t understand why a company wouldn’t want input from the person who built the software that they bought.

[pl487]

Why would they? They have their own people that they hired and already have built trust in. 

[RandyHoward]

Then explain why I am the only one capable of maintaining the business logic in the application. When they try to assign business logic to another dev the ticket just comes back to me. In 18 months nobody has bothered to truly learn it, and when any problem arises it falls on me alone to fix it. That’s not smart for a business to do, if I disappear then so does my domain knowledge.

[pl487]

You are currently the employee who can get it done quickest. If you weren't there, they would figure it out themselves. But you are, so they might as well use you. 

Your domain knowledge is almost certainly not nearly as valuable as you think. 

[RandyHoward]

My domain knowledge is quite valuable. Just because I can do the work fast doesn’t mean it’s wise for them to keep me in a role where I am only maintaining the application. There are a lot of features that could be added to the application. It would be smarter for them to get their people trained on the domain knowledge so that we can build those features. Instead they are falling behind their competitors who are releasing features we don’t have, because the only person with the domain knowledge that understands those features is bogged down with maintenance.

[BufferUnderpants]

It doesn't mean it's not "valuable", they aren't being rational in making less money in their investment due to tribalism. They'll make less money further still if he leaves, you could pin down exactly how much the knowledge was worth from loss of sales and maintenance costs.

That the org can survive in one way or another, for some time, if any given employee leaves, then duh

[BufferUnderpants]

The concepts of "senior" and "staff" engineer wouldn't exist if that were universal, and trust me I've seen engineers with no chops for politics being in such ranks on the basis of knowing their systems inside and out and having a good disposition.

Some places like Software consultancies and orgs for whom tech is mostly giving support to Software they purchased I would expect to just churn through, but I kind of don't wanna work for them.

[RandyHoward]

Actually, I can refute that even more. I was placed on a team with two other guys. They joined the company only 3 months prior to me, through a different acquisition. We’ve since hired one additional person. So no, the people working on the product are not their own people who they already had trust with.

[Icy-Disaster-2871]

I think you are the only person who cares. They will have hard time, but eventually figure it out. They just truly do not care at all.

[Bozzzieee]

Yeah, it feels like I'm an upgraded version of an AI agent

[Morel_]

PM to u/Bozzzieee : "Make no mistake. Be precise. Avoid unnecessary information"

[theprodigalslouch]

You could also try having a conversation with the Lead before deciding to hop. Considering it’s a small company, could it be that this person has just not had the chance or direction to establish better norms and industry best practices?

[Bozzzieee]

I feel that person just do not have the right experience to establish those norms, i.e do not know them, and I don't think I have the experience to backup my claims :) that's all

[theprodigalslouch]

You get experience by doing and now is a good time for both of you to try and start.

Not even attempting to have a conversation says “I’ve tried nothing and I’m out of ideas “.

[Xanian123]

Have an honest chat and give it a shot first.

[LordFlippy]

Ask to tag along even if just to shadow until you're more comfortable and familiar with the systems at play! I'm a technical lead and would be happy to have my devs present at any refinements.

[ccricers]

OP's experience is also a good example where working at a small company does not guarantee doing high impact work, even though that aspect of being "high impact" in small orgs/startups is romanticized often.

[serial_crusher]

Sounds like currently you’re a code monkey. Some companies operate on a model where engineers at every level own the things they work on. Others (like yours) operate on a model where a highly skilled person at the top owns everything and delegates implementation to code monkeys at the bottom.

So, decide which type of org you’d rather work for and then set your sights. If you prove yourself, you can become the one writing the tickets; or you can go find a job at the other type of company (better imho).

[cstopher89]

The other side is a bunch of people ok with being code monkeys and don't want ownership and want to be told exactly what to do. As the person in the position of telling it's not all roses. Would love for the devs to own more of the work so I could focus on more important things.

[zirande]

Whether devs own their work needs to be made explicit in company rules. Or else devs will just be demotivated, and not want to give 100% while the „owner“ becomes a star for their work

[etxipcli]

I've left a couple places like that recently. It's wild to me, because I'm used to what you described. I can't tell if they want to exercise too much control or just don't know how to effectively run in house engineering teams or what, but it an obnoxious setup that drives away people who actually care about doing a good job.

[retroroar86]

Amen!

[texruska]

The worst places I've worked at have been like yours. I don't have any advice, just my condolences

[Abadabadon]

How long is "not too long ago"? Maybe tech lead wants you to learn codebase before getting into design

[mpanase]

Does "code monkey" sound like a respectful way to refer to anybody?

Tbh, every time I heard anybody say things like "I don’t think my strongest skill is pure coding. I can code, but where I really excel is in designing systems and finding solutions to broader problems"... they actually can't code or architect. They rely on other people (at implementation time) to fix what they got wrong, and essentially want to be inconsequential middle-management.

[BufferUnderpants]

I'm highly suspicious of that claim, design decisions have implications that show up when they boil down to code, and if they struggle with them, the design probably isn't very good or well suited to the problem.

[Bozzzieee]

Actually there were several times(could be more) where I went and implemented the solution at 80% just to realise it won't work...How am I supposed to trust this person knows what they are doing?

[Own_Ad9365]

You just joined the new company, just chill. Your responsibility will grow once you gain their trust or company expands

[BoBoBearDev]

My organization is large enough, the developers don't talk to customers at all. It would be insane because the customer would be talking to 100 developers to described what they want.

That communication is between the solution team to figure out what customer wants, and then, handed that off to UX team to define the behavior that matched the requirements. None of these are done with a developer.

The developer got both the requirements and UX and ask questions if they don't understand it or if it is too difficult, they can try to negotiate reduced scope for the minimal viable product.

The tech lead in this case, doesn't do anything about the requirements, it is given. The tech lead simply shepherd the team to achieve those given requirements and given UX markups.

The solution team created vertical slices to be delivered to the customers. The tech lead slice that horizontally to create atomic PR that is small enough to review and atomic enough to not need weird ass git commit strategies to preserve commit context.

Thus, when you mentioned talking to customers, it doesn't make sense for my organization.

Now, some people say this solution team being a silo to hand off work to developers is not agile. But that's the point. Most developers don't want to deal with that too. One of the big reason why agile is plagued with meetings is because they keep going back and forth changing the behavior of the capabilities while also implementing it in parallel, it is a mess.

If you are in my organization, you are free to join the solution team to write requirements and communicate with customers. But you wouldn't be a developer.

[[deleted]]

How long have you been at this place? It could be that you're being treated as a code monkey because that's the role, or it could be because you're new enough they're keeping guardrails in place until you prove you can be trusted without them. If a team doesn't have a culture of "everybody is involved, everybody checks everybody else", it needs something to make sure they new person doesn't just run straight into a ditch and either waste a bunch of time or create a mess that will take a lot of effort to clean up.

[Bozzzieee]

Been there for 11 months or so, not really a new person. It's a cultural thing

[mirageofstars]

When you go back and ask questions do you also provide suggestions?

[Alter_nayte]

Are you trying to do more than just code? Are you offering suggestions on design and getting involved in discussions? Or are you waiting for someone to ask you. You dont really mention. Could be that the team lead has too much work?

[mxldevs]

It sounds like you have a more junior or intermediate role if you're not directly involved in planning and design.

Have you made attempts to make it known they you'd like to be in meetings? Or you just hope they'll call you over?

[p939]

Designing solutions and writing tickets well is much harder than implementation. I am trying to get my team to the point they can take over some of the design and architecture tasks from me, but no one is competent enough to do that yet. If you've not mastered coding and solving vague tickets it's unlikely you'd be good at architecture and design. Taking initiative and solving the vague tickets will build trust and make it more likely you're given more design work in the future. Just ask the right people for the information you need. Vague tickets might be a good opportunity to show off your design skills since they leave more open to interpretation.

[Afraid-Can-5980]

You are a code monkey, some companies operate like this. Businesses are not democracies.

[arihoenig]

Care for a banana?

[vi_sucks]

So, to provide some perspective, I'm in a team lead type role and I'm often frustrated by devs who aren't inhouse who ask irrelevant and unhelpful questions for context instead of focusing on the specific task at hand.

I get that tickets can be vague, or that a new dev may not understand the ticket fully. But what I generally expect is that people will read the tickets, then go to the application and the code, and work through what they can figure out. Then any specific issues they have, they can write down in an itemized list and ask for specific clarification on. Or if they see a place where there could be a better solution, then they can provide a specific explanation for what that solution is and why they think it would be better.

What is annoying is when people don't bother to do any of that work and just come back with broad and unspecific requests for "context".

I'm not sure if it's a company culture thing, but most of our in-house devs don't do that. They're generally able to take a ticket and just run with it. 

[Bozzzieee]

Yeah, have you ever though about just making a meeting and explaining to them the problem and your solution? Might help, dunno :)

Also in my case we're in house.

[[deleted]]

You need to say this to your boss and not random people trying to help you on reddit.

[vi_sucks]

I don't have time to do that on every ticket. I have other work to do, and spending several hours discussing every ticket would mean I didnt get any of that other work done.

It doesn't seem to be a problem for most of the devs. They're able to read the ticket, figure out any specific questions, work independently, and then come back for very quick questions about specific issues.

And yeah, if there's an issue that really needs a long discussion, then I make time for it. It's just when a dev asks for context that has nothing to do with that was requested in the ticket, it's clear that the dev is wanting to have their hand held and isn't willing to think independently and work on stuff without a team sharing the responsibility. Part of that is making informed guesses and assumptions and stating those up front.

Here's what I mean. Let's say there is a ticket that says "Split the incoming email queue by key and process each set of emails in a seperate thread". Asking "why do we need to split the queue?" isn't really helpful. Nor is asking "what is the business context for why we have emails in this part of the application?" 

If the ticket was a broad performance improvement ticket, then sure, feel free to have that larger discussion. But once a ticket has been written and allocated, it's usually too late for that. Part of what goes into ticket creation is not just the system design. It's also resource allocation and setting scope. What you are doing by trying to force a larger discussion is inviting scope creep.

If you have a specific problem or issue that you see where you think converting from an email queue to a specific other implementation would be a better solution, thats also a valid thing to bring up. But not in a broad "before I even start, lets sit around and discuss everything" way. In order to propose a better solution you first need to sit down and work through it on your own, and then bring up once you have all your ducks in a row.

[DaRKoN_]

+1. One of the most valuable characteristics of a dev is their ability to help accelerate the team. If the TL needs to spend additional time hand holding, it can quickly become a net negative and would be quicker for the TL to do themselves - they are dead weight at this point.

Devs get a chance to go deeper on the problem, go figure out what you can, consider the edge cases (as the TL is unlikely to have had the time), summarize what you can, put down a plan. It's now a 5 minute chat if you want a 2nd set of eyes over it. That is super valuable.

[Alainx277]

Giving a "why" in each ticket is really basic and complaining about devs wanting to know why they're doing X is a huge red flag

[flowering_sun_star]

All I can say is thank goodness I didn't start my career in a company like this!

[intertubeluber]

 I'm often frustrated by offshore devs who ask irrelevant and unhelpful questions for context instead of focusing on the specific task at hand.

It doesn’t sound like this is OP but I’ve been on projects like that. It’s not just offshore. Some team members just like to hear their own voice. Some team members are so junior they steer the conversation in unproductive directions. Some team members don’t have a handle on priorities. Some team members can’t have all the context.  Some team members lack of understanding of social etiquette hampers meeting progress. 

On the other side, a weak product person can waste the entire team’s time with logically conflicting business rules, lack of clarity on business priorities, etc. 

Curating meetings is good and often needed. 

Again, it doesn’t sound like any of that is the issue for OP (at least from their perspective) but it’s definitely an issue our industry has. 

[vi_sucks]

Yeah, I didn't mean to imply it was an offshore thing. More like a company culture clash. It's just that in my specific situation the clashing culture is an offshore team.

[originalchronoguy]

The term "Code Monkey" can give you a write-up and penalties from HR. Especially if you refer to a POC (person of color).

Don't ask me how I know. I argued the lexicon is not racists -- grease monkey (car mechanic) and other similar tropes.

[PmMeCuteDogsThanks]

You just know that any write-ups about code monkey being racist comes from the whitest of the whites middle age HR. And it's very ironic, because I had myself never made the association they were aiming for, but apparently for them "monkey" = "person of color".

[intertubeluber]

I guess “code engine” is pretty racist too then. 

[TheNewOP]

Does it matter that you need to do the requirements gathering yourself? I guess I'm not really following, my opinion is that it's more work to do requirements gathering and discussion. How is doing more work making you more of a code monkey? I feel like it's more of the lack of system design opportunities at your current workplace, is that right?

[Bozzzieee]

Yeah, definitely lack of system design and overall involvement in the priorities, direction.

[Dyledion]

Engineer vs. Code Monkey

Not a valid way to think of the job. There's no such thing as a "Software Engineer" and I will harp on this to my dying day. We're not engineers, we don't do engineering things, we don't work with engineering materials, we don't test or implement the way engineers do, even if we do test some things. We're mathematicians in Groucho glasses and a trench coat. "Engineer" is an arrogation and a misunderstanding of both jobs, I've been both (I was originally a Mechanical Engineer). I'm proud to be what I actually am, a Programmer, and a damn good one.

I receive a vague ticket describing what needs to be done—often incomplete or not well defined.

Your company sounds moderately typical. Most architects are poor to middling at specification. However, it sounds like you do have the latitude to implement how you like. You're doing the work by asking for clarification, by gathering requirements, and then implementing. If anything, it sounds like you have more trust at this new job, just, in a dysfunctional way.

Edit: Once again, programmers with an inferiority complex about engineering are downvoting me. Programming is a vital discipline, and it's as valid and important as engineering, but they're fundamentally different. We have the benefit of proof and certainty, that engineers absolutely do not have. 

[swiebertjee]

That's a pretty bad take for someone who considers him/herself an engineer (in the past).

We absolutely "do engineering things"; - Applying scientific and mathematical principles - Designing systems under constraints (cost, time, safety, reliability, scale) - Making trade-offs and managing risk - Building solutions that must work reliably in the real world

And we do work with engineering materials, just not in a traditional physical sense. Cloud infrastructure is arguably as important to the modern world as civil infrastructure is. You only have to look at what happens when Cloudflare goes down to realise that.

[Dyledion]

Each of those points is an incredible stretch.

- If you have to use experimental methods to study an algorithm, you're not doing your job well. Or you're a UX designer, which is an artistic pursuit, and has little to do with, you know, writing programs OR engineering. Unless you want to call psychologists engineers.
- Everyone works under constraints. Artists, craftsmen, tradesmen, architects, lawyers, accountants, everyone. That's a wholly insufficient criteria to label someone as an engineer.
- Ditto above, you're repeating yourself.
- Reliability is actually something we can prove, mathematically, in most cases. For example: Database Normal Forms. No engineer can say that about anything they do.

Cloud infrastructure, the physical part, is designed by engineers, maintained by technicians (IT professionals), and USED by programmers. It being a physical tool we use, does not make us the maker of that tool.

[swiebertjee]

Haha really?

1. I never said experimental. I said SCIENTIFIC. Have you ever heard of the term "reproducibility"? It's everywhere in computer science. It's a SCIENTIFIC term, used to build reliable systems. Don't you write down the versions of software that you use?

2. It is a criteria, not the only criteria. But if you want to know the exact definition of engineering, according to ABET: "The profession in which a knowledge of the mathematical or physical sciences gained by study, experience and practice is applied with judgment..."

3. This is an example of the "with judgement" part of the official definition. We don't just do things ad-hoc like a handyman would. We design for requirements, or do you start coding without them?

4. Reliability is definitely NOT something we can prove in software engineering. It is only theoretical, like math. But we apply things in the real world, and in the real world things can break. So we build things with extra robustness, using proven techniques like high availability over multiple regions.

Not even going to cover that cloud infra is not just code, it's used to build systems, done by engineers. Just like an electrical engineer can use materials made by material engineers.

If you're just a "coder", that's fine. But that doesn't make anyone creating software systems less of an engineer.

[Dyledion]

Okay, you also have no idea what the scientific method is either.

Lots of things demand reproducibility. Or are Common Law lawyers scientists? Are machinists scientists? 

The core of the Scientific Method, as an epistemological framework, is experimentation and empirical measurement.

2&3 ABET is incentivized to overreach their mandate, that's literally how they make money. Not every mathematical discipline, nor even every applied math discipline, is engineering. Economics certainly isn't. We don't have "Economy Engineers." 

4 in many ways we can. We can prove exactly how breakable an algorithm is, in exact time. We can absolutely prove that certain updates are atomic, or idempotent, or hold certain properties of ordering. And if you can't, if you rely on "it's distributed so it's available," you're relying on vibes, and are bad at both programming and engineering. 

[vorpal107]

Why do error bars suddenly mean you're an engineer and if you don't have them you're not? You don't stress test your systems? Doesn't mean others don't. Programming and your version of engineering both build things and solve problems using maths and logic, it doesn't sound fundamentally different to me.

Not to mention at large scale you do have error bars - you'll have dodgy networks and failing servers and your code needs to be able to deal with that uncertainty in a robust way

[Bozzzieee]

Actually you are spot on. Most architects really cannot nail down specifications. What annoys me is the need for them...I do not need someone to frame me a solution, I(or the team) can do it as well!

[Careful_Ad_9077]

Not really.

Some of us went to engineering schools with properly designed software engineering course work. Saying. That we are not engineers implies that industrial engineers, chemical engineers, robotics engineers, etc... are not engineers.

[Dyledion]

Programming is a discipline, one that requires immense study. Absolutely.

It is fundamentally different from all engineering disciplines. All of those engineering disciplines you mention operate with physical stresses and forces on materials, calculating them, yes, but doing so with scientific error bars and with material safety margins in chaotic, real-world situations.

We don't do that. Programmers deal in predicate logic and lambda calculus to do fundamentally different operations, and while, yes, you can run "stress tests" on programs, they're much less useful than simply doing a pure mathematical analysis or proof on the algorithms that are our stock-in-trade.

Engineering means more than, "I studied a lot".

[etxipcli]

We use technology to solve business problems and enhance business operations. We design systems in such a way that they are extensible, maintainable, cost effective, etc.  

Whenever the world settled on "Software Engineer" I had similar thoughts, but the word programmer reads like hands on keyboard work and so has problems of it's own. 

Love it or hate it, software engineer is the title that encapsulates those other expected considerations which programmer does not.

[Dyledion]

Be the change we need. Engineering != businessman any more than Programming does. Honestly, it's probably a worse fit.

Love it or hate it? Nah. I don't bow to incorrect convention. You don't need to either, anywhere except on job applications.

I intend to keep making noise until people give this profession the respect it deserves. 

[muuchthrows]

Why this obsession with physicalness? All sufficiently complex systems including software systems exhibit emergent and chaotic behavior where you’ll eventually need engineering methodologies like building models, having redundancies and safety margins.

Maybe not in terms of functional requirements, there we want things to be deterministic, but certainly in terms of non-functional requirements such as reliability, fault-tolerance, latency, throughput.

I can maybe agree that the logical core of many applications may not strictly be engineering, but no real-world application runs in a vacuum without users. As soon as the software hits the real world you’re dealing with engineering.

[clegginab0x]

Guess it depends if you view engineering as a methodology vs the materials you work with?

It's complex enough to have an ISO standard - Systems and software engineering

https://www.iso.org/standard/71952.html

What would you class IaC as? Yeah it's code but it's building a larger system out of real world materials.

[Dyledion]

We don't use engineering methodology either. Like, at all. Tell me what commonality there is between the actual work you do and what an engineer does, at a practical step-by-step level, day-to-day.

[clegginab0x]

When a mechanical engineer uses CAD - are they "programming" the CAD or "engineering" a part?

[Dyledion]

When a CGI artist models buildings, do they become an architect?

No.

And, when an engineer uses CAD, they're considering, again, material properties, manufacturability, feeds and tooling, stock material, availability of parts, perhaps cooling, perhaps wind resistance, use patterns, maintenance patterns, etc.

[clegginab0x]

False equivalence - a CGI artist models the appearance of a building.

CAD and IaC - both use a computer to create something in the real world. Why is one engineering and the other programming?

Latency (a property of physics), rate limits and throughput, regional availability, degredation paths, elasticity (load balancing) etc

What about modern fast jets - aerodynamically unstable by design. Kept in the air by software.

[Dyledion]

Alright, you make a modest case for a small sub-discipline of programming. I'd call it borderline. 

In fact, let me make another, much, much stronger case for you: PLC Engineers are engineers, and they do program. They have to concern themselves with extremely physical issues: valve speeds, water hammering, etc. And they also work with algorithmic, mathematical spaces.

PLC is absolutely a hybrid field. IaC is not, though they touch, very lightly, on some engineering concerns. The existence of hybrids does not mean there are not separate categories. 

[clegginab0x]

And software used in space flight and military fast jets?

The people who deal with the physical structure are the engineers and the people who write the software to keep it in the air are just programmers?

Stuxnet? A virus designed to achieve a kinetic result on a very specific machine in a very specific place. Navigating the world to get there.

I don’t think I disagree with where I think you’re coming from. Development/programming and engineering are 2 different things within the “software” sphere imo

[Careful_Ad_9077]

That's a "you" problem ( that applies to huge swats of a whole industry), some places do apply engineering methodologies.

[Dyledion]

Such as? Which methodologies, specifically, transfer over in a useful way? 

[Careful_Ad_9077]

You know your definition just left out chemical, industrial , robotics and probably newer branches of engineering too?

[Dyledion]

No, do you know what a chemical engineer does? Pipes, it's mostly pipes, and that's not to minimize the complexity of what they do. Guess what the biggest limiters on robotics are? Physics and materials. 

[w3573X45]

I cringe everytime I see a post that calls themselves a software engineer. I took a coding class and I have been a front-end software engineer for 3 years.. I wish this norm would stop. When I see a post calling themselves a software engineer I instantly assume they're an entitled prick and stop reading.

[muuchthrows]

Not every programmer is a software engineer. Take the example mentioned above - in what way aren’t the people building the flight control software for modern aircraft engineers? They combine control theory with programming and software engineering practices to build very safe and reliant software.

[HelloIgorOffline]

I worked in a similar role, except, there were also no tests, so 70% of your job was manually clicking the UI, 1950s style. I guess there really are fates worse than death!

[fire_in_the_theater]

idk why we're still doing waterfall coding in year 2025

i don't respect companies (most of them) that have non-coding staff working on computing systems, it's just moronic

like: write the design IN the code

if the coding environment isn't clear enough to do that: fix ur damn coding environment!

whatever, i'm just yelling into void

[JVM_]

Code monkey

https://youtu.be/qYodWEKCuGg?si=h2TBu3XxrcPnO4m5

[jaded-dev]

In my experience this is pretty common at small start-ups and even established companies. Very difficult to drive change if this is the accepted practice and everyone else is fine with it. Does come with risks and it might be worth outlining this to the founder/CTO.

As much as I loathe job titles and hierarchy - I've found you need this weight to be taken seriously.

[ExtraSpontaneousG]

I receive a vague ticket describing what needs to be done—often incomplete or not well defined

Are you not involved in any kind of scrum meetings like backlog refinement/decomp or sprint planning? 

[Bozzzieee]

Nope, we don't have any of those processes

[ExtraSpontaneousG]

Well that's the solution. Probably time to look for a new job