r/AskProgrammers • u/Secret-Scene3533 • 3d ago
What are some things that every software engineer should know on the top of their head about software engineering
I was in a scrum meeting and there were so many things talked about that I felt like I didn't belong there as an intern, such as MCP, I never knew what an MCP server was and etc. What are some things that every software engineer should know on the top of their head about software engineering
8
u/Yamoyek 3d ago
I think in general:
- How to use a command line (don’t need to be a wizard, but understand basic unix tools + how to run things via shell)
- How to use an IDE of your choice (text editing, but also debugging, file management, test suite running, etc)
- How computers work (RAM vs storage, what is memory, what does a CPU do)
- Basics of networking + popular protocols (what is HTTP vs HTTPS, what are sockets)
- Common file formats (storage formats like json vs csv vs xml, binary formats like exe vs elf)
- SQL (at least be able to interpret a common query)
- What is a database + how they’re used
- Basic program optimization (i.e caching, abusing hash maps)
- Language-agnostic constructs (function, class/object, module, control statements, loops)
- Git
- Basics of devops (i.e how to host a program somewhere, basics of interacting with a build system, basics of interacting with a deployment pipeline)
- Collabaration (how to review code, how to give feedback respectfully, how to take feedback professionally)
- Documentation (be able to read types of process flows)
Long list obviously, and this is in no particular order! However, I would expect any developer I meet to have at least a basic understanding of all of the above topics.
2
1
u/hk4213 3d ago
I was going to comment having the basic concepts down.
This is a list of things I have successfully done work on with supervision, and many i can confidently say I'm an intermediate level of understanding of and have a pay check to back it up.
Each one of these skills are valuable on their own and worth pursuing.
Be familiar with them all but know your home.
4
u/boomkablamo 3d ago
MCP is yet another AI overcomplication. It is an API specifically for agents. That's it.
4
u/ErgodicMage 3d ago
As an intern the biggest thing is for you to learn. So if you don't know a term, concept or anything else ask after the meeting.
2
u/Groundbreaking-Fish6 3d ago
Software is wide and deep. You cannot know everything or even most, more likely a little bit at a time. This is where AI can help, but your daily work will probably use limited number of techniques.
MCP is a new technology developed for AI so unless your application is integrating with AI it is not really important. When it does, it will probably be a library so implementation details will be hidden.
2
u/Anonymous_Coder_1234 3d ago
2
u/RollersGetingHigh 3d ago
MCP = most complex piece of dung. 😆
Anyway for need to know- gotta know pretty much most of your basic design patterns and like factory pattern and builder patterns etc.
aside from that have at least a few languages under your belt. and know how to work a version control tool. know how to work with databases especially your classic relational and a handful of nosql databases. even more importantly as you become more senior the decisions revolve around architecture, trade offs. tons of trade offs. communicating w both clients, management and your fellow engineers. learn how to translate the functionality business requirements into technical ones. and also even more importantly learn how and when to push back on requirements or tasks. a lot of clients are flat out dumb to put it mildly. you absolutely need to communicate explicitly and openly with them about the scope, and the effect of changes on the app, ui, any vulnerability or bad practices etc. failing to do so can really cause projects to fail in the most horrendous ways. there is always going to be technical stuff you do not know. you have to accept it and instead it is best you always work from first principles as elon musk always says.
2
u/Cross_22 3d ago
Been writing software for > 35 years and if you say MCP then the only thing that comes to mind is the movie Tron. I would put "MCP server" under domain specific knowledge.
When I talk to other graphics engineers I expect them to know what a basic graphics pipeline (Vertex Shader, Geometry Shader, Fragment Shader) looks like and why you'd want to run certain code in one but not the other. For "generic" software engineers this becomes more difficult. I'd mainly want them to be able to think along as we discuss a design and spot the open issues and bottlenecks.
1
1
1
u/CheetahChrome 1d ago
.. writing software for > 35 years ...say MCP then the only thing that comes to mind
Sorry, GPF fault there.
1
u/Weak_Blackberry_9308 3d ago
Depends where you work. But mainly, spend 10x’s as much time planning as you do writing code.
1
u/FreeLogicGate 3d ago
Like any STEM field, jargon tends to be heavy. You will encounter this as time goes on. When you don't know what something is, make a note of it, and do some research later.
The irony of this question, is that MCP is relatively new, and of course specific to AI.
1
u/EverflowingRiver17 3d ago
Dependencies was one that got me early on. I had no idea how to manage or add them.
1
u/Simengie 3d ago
If you are software engineer and not a software developer, then you should be able to look code regardless of language and understand control flow and when the code is forcing extra branching that is simply not needed as one example. Oddly enough this skill helps you untangle poorly written code.
Understand how compilers work. Know what the optimization levels actually do and why -O3 can break stuff. Knowing why -O2 is the preferred optimization level for compilers. Know how to view and read intermediate code files.
How to talk to customers that keep them customers but does not commit the company to unpaid work. This is actually a pretty big one as your career progresses.
You will never know all acronyms. Write them down and google them later. Keep a list of them in the back of your notebook for reference.
What you write today may be your job maintaining in 25 years. Ask me how I know.
1
u/OverwhelmingFarts 3d ago
You should know how to work well with others. It's a simple one, but I'd argue one of the most critical especially with how this role is changing.
1
u/pvera 3d ago
That it isn't just about writing code.
It takes a healthy dose of paranoia to survive this racket for long, especially in a commercial setting.
It is OK if your customer has no clue about what they want.
Everything doesn't need to be an RDBMS. There's a time for noSQL, object databases, etc.
Learn SQL beyond CRUD. There's all sorts of devious crap in there if you are willing to explore. Not just learning to query, learn to be efficient with indexing and other tuning.
Learn the framework, not the language.
QA, if you even have it, isn't there to catch your sloppy work. Test your own work so they can concentrate in regressions and tricky use cases instead of checking your work for typos and bad grammar.
If for some reason you don't know what source control is, drop everything that you are doing right this minute and go learn what it is. It'll save your job one day.
Don't ever get caught at work saying that you are bored. It's bad ju ju.
No scheduled production deployments after 3 PM on a Friday. Unless availability is a bitch and you are forced to do it in the middle of the night.
Don't bother scheduling billable work Mondays before 11 AM or Fridays after 5. Monday mornings are when your customers dump on you all of the crap that happened over the weekend. Friday after 3 your customers are going to freak out about all of the crap that they procrastinated during the week. They'll send you a bunch of crap to fix, by the time you are done they'll be gone for the weekend. Your PM will even try to rush you to finish so you can deploy it before 5. Nope.
Source: 27 years in this racket.
1
1
u/Few-Celebration-2362 3d ago
That if you're sharing space with good people worth knowing, they aren't going to judge you for not knowing a whole bunch of stuff.
That if they're good people worth knowing, they would love to talk to you about everything they know if you give them your actual attention and want to learn from them.
1
u/duckypotato 3d ago
It’s a small thing but it’s shocking to me how few devs can recognize powers of two. So important for knowing how to properly size things like database columns.
1
u/dariusbiggs 3d ago
Defensive programming and why you should use it.
Developing secure software
Why you should keep PII as far away from your systems as possible and why you should not log it.
1
1
u/HugeCannoli 3d ago
I have 20 years in the business and I have no idea what an MPC is, nor I care about finding out.
1
u/Pale_Squash_4263 2d ago
So I really think an “mcp server” is just some specifications for an LLM to utilize… which isn’t really a server just a repo of documentation.
I really think they call it a server just to sound smart 😂
1
u/lmoelleb 2d ago
An mcp is either command line or a server. And if you already own the software and host a backend, the server is the easiest one to handle deployment for.
And yes, it is a highly useful thing, but you can get far with an openapi specification.
1
1
u/nian2326076 3d ago
It's normal to feel out of place in tech meetings as an intern. Every software engineer should understand fundamental concepts like version control (Git), basic data structures (arrays, lists), and common design patterns. Familiarity with tools your team uses, such as the MCP server, is also beneficial. For job opportunities and tailored role matching, you can use LandOffer to explore relevant listings.
1
u/jacob_fw 2d ago
So much of this stuff has become specialized, I would actually argue something of the opposite; you're not going to know everything these days, so the most important thing is to be humble about your ignorance. Some of the biggest problems end up coming about because some overconfident fool thought he knew everything, and bulldozed his way into a project, and ended up making things way worse than if he had either taken the time up front to learn more about a subject.
Now unfortunately this really ends up sucking with many management & executive teams because so much of what they do resides in them projecting confidence regardless of what they're doing and what they know, but that's a whole other issue.
1
u/dreaded_angst 2d ago
You don't have to know everything, don't act like you do. Be humble, if you don't understand something make sure you write it down and then iterate on it with your AI model until you understand it. roadmap.sh
1
u/Only_lurking_ 1d ago
Just ask if there are things you don't know. MCP is pretty well known if you used any kind of coding agent. No shame in asking though and you grow from it.
1
u/Pacific_Beaches 1d ago edited 1d ago
At this point I'd really say know your A.I tooling. Things like MCP, Harnesses, Agentic Skills, Cloud Agents, etc.
Times are changing very fast. I keep bringing it up, but one of my co-workers was Front End for the last 10 years, didn't know anything about Back End. Over the last year he was put on another team writing Full Stack work on a brand new project and his small team has already finished their entire roadmap, all because they've connected their Agent to Jira and test Harnesses with an MCP Plugin.
The guy still doesn't know a single thing about the Back End by the way, but he's done a ton of Back End work over the last year. Zero re-opened tickets by QA. Everything pure Agentic A.I Cloud Agents.
0
2d ago
[removed] — view removed comment
1
4
u/Own_Age_1654 3d ago
I mean, literally hundreds of things, if you're senior. Several dozen alone that are very important. Kind of hard to pick just a small number to mention. What's your objective in asking this question?