Two years ago, when I got my first freelance client, I was still in my final semester of college.
A guy approached me on LinkedIn because he wante...
For further actions, you may consider blocking this person and/or reporting abuse
As an introvert, I hated socializing, making small talks, and even approaching new people. That was my biggest weakness. I even got called a "snob" many times but they don't know that I was just shy and awkward with talks.
Now, I realized that communication is king when you want to progress in life, not just in careers. If you just stay cooped up and doom scroll your way towards the end of the day, nothing will happen. Even if you are the greatest engineer out there, if you don't post and socialize, you're invisible.
So I say this, people will judge anyway. Post your achievements, show your flaws, don't be afraid to fail. Being shy would get you nowhere. This is the hard truth I forced myself to swallow 2 years ago. Glad I realized it sooner and not let my pride and ego took over.
Genuinely appreciate you sharing this as the growth from "snob" labels to owning your voice is real and earned.
I'd push back gently on one thing: there's a difference between developing communication skills (which is genuinely valuable) and being forced to perform visibility on platforms constantly, and I think this framing blurs both.
When we say "if you don't post, you're invisible" ,we're not describing a law of nature. We're describing rules written by companies whose entire business model depends on us feeling exactly that pressure. The hard truth here isn't really about human connection. It's about accepting a system where our output, attention, and vulnerability become someone else's revenue.
Shyness as a weakness?? Fair conversation. Chronic online presence as the price of being "someone"? That's a much more loaded premise worth questioning, especially when the ones truly profiting from that belief aren't us.
I actually agree with a lot of this.
I don't think constant posting, personal branding, or living online should be a requirement for being valuable. And you're right that some platforms absolutely benefit from making people feel like they need to be perpetually visible.
The distinction I was trying to make is closer to communication than content creation.
For example, being able to explain your work, ask questions, build relationships, share ideas, collaborate, or advocate for yourself when opportunities arise.
Those things existed long before social media and would still matter if LinkedIn disappeared tomorrow 😭
That said, I do think it's healthy to question where the line is between genuine connection and performative visibility. That's probably a conversation more people should be having.
I think one thing I've slowly realized is that communication isn't just about talking more, it's about reducing friction between yourself and other people.
Whether that's asking for help, sharing ideas, building relationships, writing posts, explaining decisions, or even just making yourself visible enough that opportunities can find you.
And yeah, the "people will judge anyway" realization is oddly freeing...
Might as well build, share, learn, and let people think what they want.
Glad you figured it out when you did.
Problem with „reducing friction between yourself and other people“ is that you may end up working much harder than you should, to make everyone happy.
That's a really good point actually.
I think there's a fine line between reducing friction and people-pleasing.
The way I'm starting to think about it is: reducing friction should help communication, understanding, and collaboration move more smoothly. It shouldn't require constantly sacrificing your own boundaries, priorities, or well-being to keep everyone happy.
Honestly, that's another lesson I'm still figuring out in real time 😅
Learning how to work well with people is one thing.
Learning where to draw the line is probably just as important.
Communication is BIG. It wouldn't make any sense to have without communication.
This is a philosophical thing. For example, if you learn everything about oranges like what is suppose to taste like and it's chemistry, do you know what it taste like? No.
The only way to know is to eat the orange.
What I am getting at is you have to experience the coding job to get the full experience than looking at other people doing the job. This is why it is dangerous to look at "life as a software engineering" videos you see because it only captures on what you see, not what they are feeling.
Good work Aryan!
Thank you Francis 😄
The orange analogy is actually a really good way of describing it.
I think that's what surprised me most. Before entering these environments, I could intellectually understand that communication mattered. But understanding it conceptually and actually experiencing it are two completely different things.
It's like reading about swimming versus getting thrown into the pool 😭
And yeah, I agree about those "day in the life" videos. They're useful, but they mostly capture the visible layer. The feelings, uncertainty, awkward conversations, and learning curves underneath are much harder to see.
Really appreciate you reading as always 🙏
Yes, coding looks like 100% of a developer’s work from the outside, but in reality it’s more like 33% documentation, 33% coding, and 33% testing, with communication involved in all parts. Also, when it comes to developing personally, marketing becomes quite important since no one notices you. That’s me. 😅
Honestly the marketing point is exactly what pushed me toward writing this 😭
The more things I try, the more I notice the same pattern repeating:
The visible thing gets all the attention.
The invisible thing is where most of the work happens.
People see the app.
Not the communication.
People see the post.
Not the positioning.
People see the result.
Not the coordination underneath.
And yes... as someone currently learning marketing, getting people to notice something you've built is an entirely different skill tree LOL.
Ah! Maybe I need to learn a little marketing to get more attention!🤔
The interesting part is that companies still mostly reward visible output.
Closed tickets.
Fast delivery.
Quick fixes.
But some of the most valuable engineers I've worked with looked "slower" because they were reducing future pain instead of generating present-looking velocity.
This is such a good observation.
Some of the most valuable work I've seen people do lately doesn't necessarily look productive in the short term.
Preventing future problems, reducing confusion, documenting context, helping others understand a system, making better decisions... none of those create immediate-looking velocity, but they compound over time.
It's almost like there's a difference between creating output and creating leverage.
And from the outside, those can look very different.
Yes, exactly as @codingwithjiro said, start small and eventually one day you will reach a point where looking back you'll think "what was I even bothered about...". You don't have to overcome it all in a day, just start with simple things, baby steps, stack small wins and I am sure you will be able to talk to anyone anytime surely.
At the end of the day we are humans behind the code. Arguably now that building has accelerated with AI assistance, the bottleneck is more distribution and communications. Investing in soft skills such as communication is a good time investment.
That's a really interesting way of looking at it.
The AI point especially stands out to me because if implementation keeps getting faster, then things like communication, alignment, trust, distribution, and decision-making start becoming a larger percentage of the overall challenge.
The bottleneck shifts.
Which is funny because younger me thought becoming a better engineer was mostly about learning more technical things.
Now it feels more like learning how technical systems and human systems interact 😭
Always appreciate your insights Julien 🙏
This hits hard and is a massive realization most developers only hit after a few years in the trenches.
We spend so much time mastering languages and frameworks, only to realize that code is just the tool, not the destination. The real job is understanding the business problem, collaborating with people who don't speak tech, and building something that actually adds value. It's a tough pill to swallow initially, but once your mindset shifts from "how do I write this code" to "why am I building this," the entire job changes for the better. Great read.
Thank you Syed!
The "code is the tool, not the destination" part really resonates with me.
I think one of the biggest surprises for me was realizing how much of professional work happens before a single line of code is written. Understanding the problem, aligning people, clarifying requirements, communicating tradeoffs, all of that shapes the final outcome.
As a student, I thought the challenge was mostly technical. Lately, I've been realizing that knowing what to build and why can be just as important as knowing how to build it 😄
Glad the post resonated!
spent my first year thinking the hard part was technical. wrong. the calls where scope quietly doubled were the ones that actually cost me.
"The calls where scope quietly doubled" is such a painfully relatable sentence
What's funny is that when I was learning, I imagined the hardest problems would be technical ones.
Now I'm starting to realize that ambiguity, changing requirements, communication gaps, and alignment issues can create far more work than the code itself.
The code usually does exactly what you tell it to do.
Humans are a bit more complicated.
right on the re-order of hard problems — but i'd push back slightly: most of the ambiguity i've hit was downstream of technical gaps. undocumented APIs, missing types, unclear ownership. the soft problems surface loudest when the hard infrastructure is already weak.
That's a really good point.
Now that I think about it, a lot of the ambiguity I've seen recently comes from missing context more than difficult people.
The communication problem is usually the visible part. The root cause is often buried somewhere in the system itself 😭
exactly — and the trap is treating it as a people problem because that is the fix you can actually point to. system-level missing context is harder to name, easier to route around, and never gets the postmortem.
Personally, I just practice explaining something, say for example, how I code. From there, I can up my confidence and push through into making conversation when an opportunity arises.
Half of software development is coding, building, testing, debugging, documenting.
The other half is social: meetings, interactions, discussions, assisting, asking for assistance, mentoring, onboarding, coordinating, presenting.
I think the two most important things I've learned in my career are these:
I wish I had known those two important things at the beginning of my career. But I learned, eventually.
That second point really hits.
"The company pays you to ship product" feels obvious when you read it, but I don't think I truly understood it until I started working.
As a student, it's easy to think the value is in writing code. Then you enter a real environment and realize the value is in solving problems, delivering outcomes, and helping the team move forward.
And yeah, the overtime point is something I'm still learning too. It's surprisingly easy to fall into the trap of measuring dedication by hours instead of effectiveness.
Really appreciate you sharing these. Feels like the kind of lessons that sound simple but usually come from experience.
Here's one of my replies to an older conversation about working overtime. Fits in with my first point, but with more blah blah.
Loved this article, Aryan. I had a very similar experience during my on-campus job. I went in thinking coding was the main thing, but I ended up wearing a lot of different hats. There was planning, coordinating with people, keeping track of tasks, and making sure things actually moved forward. Honestly, I learned a lot from that side of work. It even pushed me to do the Google Project Management certification, which I ended up finishing. It made me realize that building things is only one part of the job. A lot of the real work happens around communication, coordination, and working with people.
Thank you Hemapriya!
It's funny how many people seem to arrive at a similar realization from completely different experiences.
What stood out to me in your comment is the phrase "making sure things actually moved forward."
I think that's one of the biggest shifts in perspective. At first it feels like the job is producing work. Later you realize a huge part of the job is helping work move through a system of people, priorities, dependencies, and constraints.
Also, congrats on finishing the Google PM certification! 😄
Sounds like your on-campus role ended up teaching a lot more than just technical skills.
This resonated with me.
One thing I’m starting to realize is that the “invisible layer” around coding is often
where the real system lives.
The code is visible. But underneath it are expectations, trust, unclear requirements, old
decisions, missing context, and assumptions nobody wrote down. When those are weak, the
technical work gets harder even if the code itself is fine.
I’ve been thinking about this through AI agent memory lately. A lot of agent failures are
not just “bad code” or “bad retrieval.” They come from the system acting on the wrong
context: stale instructions, old decisions, or notes that were relevant but not actually
authoritative.
So I think your point generalizes beyond freelancing and jobs:
Coding is one layer.
Communication is another.
Context management might be the layer that quietly holds everything together.
Great post.
This is a fascinating way of framing it.
"The system acting on the wrong context" feels surprisingly similar to what happens with humans too.
A lot of the issues I've encountered recently weren't because someone was incompetent or because the code was bad. They were because people were operating with different assumptions, outdated context, or incomplete information.
Which is why your point about context management really stands out.
Maybe documentation, communication, onboarding, memory systems, and knowledge sharing are all trying to solve the same underlying problem: preserving context as a system evolves.
Really interesting connection to AI agents. Hadn't thought about it that way before.
Yes, I think that is the deeper pattern.
A lot of failures are not raw competence failures. They are context failures.
The person made a reasonable decision under the context they had. The problem was that
the context was stale, incomplete, local to one team, or quietly superseded by something
nobody communicated clearly.
Agents make that problem easier to see because the failure is compressed. You can watch
the system retrieve an old instruction, treat it as current, and act from the wrong
frame.
But humans do the same thing in slower motion:
That is why I agree with your framing. Documentation, onboarding, memory systems, and
knowledge sharing are all attempts to preserve context across time.
The missing layer is status.
Not just “what do we know?”
But:
That is where AI agent memory and human organizational memory start to look like the same
problem.
Systems fail when old context keeps acting like current truth.
The status layer is a really interesting addition.
Because you're right, preserving information isn't enough on its own.
I've definitely seen situations where the problem wasn't that information was missing. It was that nobody knew whether the information was still valid.
The document existed.
The decision existed.
The explanation existed.
But nobody knew if it had been superseded, partially replaced, or was only relevant under certain conditions.
Which is funny because we often talk about knowledge management as a storage problem, but what you're describing sounds more like a governance problem.
Not "Can we find the context?"
But "Can we trust the context?"
That's a much harder problem.
Yes, that is exactly the shift.
A lot of teams already have the context somewhere. The problem is that the context has no
state attached to it.
So people find the doc, the Slack thread, the old decision, the onboarding note, or the
runbook, but then the real question starts:
is this still true?
That is where the work gets harder.
Storage answers:
Governance answers:
And you’re right, that applies to human teams before it applies to AI agents. I’ve seen
the same pattern: the information exists, but nobody knows whether it was superseded,
narrowed in scope, replaced by a newer policy, or only valid for one incident.
The thing AI agents make obvious is that they don’t naturally carry that uncertainty. If
a memory matches the request, it may treat it as useful unless the system gives it
status.
That is why I think context needs labels like:
Without that, knowledge management becomes a pile of artifacts with no authority
structure.
The question is not only:
It is also:
That is the layer I think needs a lot more attention.
Every developer enters freelancing thinking:
“Finally, I get paid to code.”
Then 3 weeks later you’re doing therapy, project management, sales, negotiation, and decoding vague messages like:
“Can we make it more modern?”
😭😭😭
The amount of information hidden inside the sentence "Can we make it more modern?" is truly immeasurable
I feel like every freelancer eventually discovers they're also part project manager, part consultant, part negotiator, and occasionally part therapist.
The coding ends up being the easy part.
I also once thought that being a devloper simply means 'coding'. But after I started working at a company, I soon realized that the idea was completely wrong. I've spent a lot more time on meeting, documatation, communication with colleagues, planning, testing, collaborating with the sales team, and so on, than just typing code lol.
LOL exactly 😭
I think that's what shocked me the most when I entered professional environments.
The percentage of time spent "actively coding" was much lower than I had imagined from the outside.
And the funny part is that all those other things, planning, meetings, documentation, communication, testing, exist because they help the coding part succeed.
They're not distractions from the job.
They are part of the job.
Absolutely! They shouldn't be considered as waste of time😊
Communication is king - and it's an aspect that I've always liked, and have always been pretty good at (I think) - maybe even more than at the purely technical stuff!
That's honestly a super valuable strength to have.
What's funny is that I used to think communication was something separate from technical work.
Now I'm starting to think it's one of the things that amplifies technical work.
Two people can have similar technical ability, but the one who can explain ideas, build trust, align people, and communicate clearly often ends up creating a much bigger impact.
Still figuring all of this out myself though 😄
Well, especially in the earlier parts of my career I was sometimes feeling more like a "business analyst" than a developer!
I even did one customer assignment where I didn't write a single line of code - it was only about talking to business people, figuring out their organization, etc ... later on I "lost" that aspect a little bit, and moved more into pure coding (but still with an analysis component) - while also noticing that software development itself tended to get more 'technical' (web dev, frontend/backend etc) ...
Anyway, I did always like the analysis work, and customer communication - maybe it tends to get farmed out more to "separate" people (outside of development) nowadays?
That's actually really interesting to hear.
I wonder if part of it is exactly what you mentioned, as software systems became more complex, a lot of those responsibilities got split into separate roles. Business analysts, product managers, solution architects, customer success, sales engineers, etc.
At the same time though, I feel like the developers who can bridge both worlds still end up being incredibly valuable. The technical side solves the problem, but understanding the people, processes, and business context helps ensure you're solving the right problem in the first place.
Yeah "bridging both worlds", that's a nice way to put it!
I think devs who do that still exist, but it's probably more in an enterprise/company context, internal business apps/systems ...
I used to develop a lot of that kind of stuff, logistic/financial-type apps/systems - my theory is that a lot of that kind of software got replaced by "off the shelf" software (SaaS and ERP) ...
Then again, I'm sure that custom "internal" development still takes place, but probably mostly in larger organizations ...
But notwithstanding all that - like you said, developers who are able to bridge both worlds, I also still think it's a valuable skill/asset!
Just wondering how AI plays into all this - would business users now be "vibe coding" more of their own stuff (possibly supported by devs)? Are we going to see a transition away from complex "off the shelf" systems (SaaS and ERP) and conventional 'deterministic' software towards "agentic AI" based systems?
(read an article about that recently, it was intriguing although I think the author over-hyped it a bit - I had my thoughts when I read it, I should write a post about it ...)
That's a really interesting angle actually.
I can definitely see the trend you're describing. A lot of the business logic and operational workflows that once required custom development seem to have been absorbed into SaaS, ERPs, and other platforms over time.
The AI question is the one I keep coming back to as well.
My intuition is that business users will probably be able to build more of their own tools than before, but there will still be a gap between "I can make something work" and "I can make something reliable, maintainable, secure, and scalable."
In that sense, maybe the bridge becomes even more valuable. Instead of translating between business and software, developers might end up translating between business intent and AI-generated systems.
Though I could be completely wrong and we'll all be managing fleets of agents in 10 years lol.
And honestly, I think you should write that post. Even if the original article was a bit over-hyped, those tend to make for the most interesting discussions.
This really resonates.
Communication feels massively undervalued in a lot of non-tech spaces as well, even though it’s often what actually keeps things moving. Technical skills get all the attention, but without clear communication, things just quietly break down.
Glad you wrote this.
Thank you!
And I completely agree. The more I observe different fields, the more communication feels less like a soft skill and more like infrastructure.
You only really notice it when it's missing 😭
When communication works well, everything feels smooth and natural.
When it doesn't, even simple things somehow become difficult.
Really glad the post resonated 🙏
this resonates, but from the other end of the timeline. im a freelance CTO running products across three countries and three languages, and the thing that took me longest to accept is that "code is the small visible part" doesnt stop being true as you get more senior — it gets more true. these days the hardest parts of my week are aligning a sales pilot, untangling cross-border tax/legal stuff, and getting three people in different timezones to actually mean the same thing by the same word. the actual coding is almost the restful part lol.
the bit that hit me: "the deeper you go into anything, the more human it becomes." thats exactly it. and i think AI is about to crank this up — as implementation gets cheaper, the bottleneck moves even harder toward the human layer. knowing what to build and getting people aligned on why becomes a bigger slice of the job, not a smaller one. the people who can bridge technical and human systems were always valuable; theyre about to be the whole game.
good writing too — the iceberg framing is the kind of thing that reads simple but takes a while to actually earn. nice one.
Thank you Sergei.
What's funny is that when I first started writing the post, part of me wondered if this was just a "junior developer realization" that would eventually disappear.
Comments like yours are making me think the opposite might be true.
The cross-border tax, sales alignment, timezone coordination, and "do we all mean the same thing when we say this word?" examples are exactly the kind of invisible work I never imagined when I first started learning to code.
And your AI point is something I've been thinking about a lot lately too. If implementation becomes cheaper, then understanding, judgment, prioritization, and alignment become even more valuable.
The bottleneck moves.
Really appreciate you sharing your pov from the CTO side of things.
This hit me harder than I expected.
I'm currently transitioning into software development, and for a long time I genuinely believed that the job was about becoming a better coder every day—learning new frameworks, understanding architecture, building projects, and solving technical problems.
What I've been slowly realizing is that coding is often the most visible part of the work, but not necessarily the most difficult part. The harder challenge is dealing with ambiguity, understanding what people actually need, communicating clearly, and making decisions when there isn't a perfect answer.
As learners, we're usually taught to think that every problem has a correct solution. Real-world software seems different. Sometimes success isn't writing the most elegant code; it's helping a team move forward, asking the right questions early, or understanding a business problem deeply enough to avoid building the wrong thing.
I think that's why many developers experience a shock when they get their first job. They discover that companies don't hire engineers simply to write code—they hire them to solve problems, and code is just one of the tools.
Thank you for writing this. It's an important reminder that growing as a developer also means growing in judgment, communication, and understanding people, not just technology.
Thank you Aalaa.
This line especially stood out to me:
I think that's part of what makes the transition surprising.
In school, most problems are designed to have an answer.
In professional environments, a lot of the challenge comes from ambiguity. Multiple valid approaches, competing priorities, incomplete information, changing requirements, and trade-offs everywhere.
And you're absolutely right about companies hiring people to solve problems rather than simply write code.
That realization has probably been one of the biggest mindset shifts of my first year working.
Really appreciate such a thoughtful comment 🙏
Great perspective. Many people start their careers thinking coding is the entire job, but quickly realize that communication, problem-solving, collaboration, and understanding business goals are just as important. Technical skills build the product, while strategic thinking helps create real value. At Aqva Marketing, we see a similar pattern in digital marketing—tools and tactics matter, but understanding customer needs and business objectives is what truly drives success.
Thank you!
I think that's exactly what surprised me most.
As learners, we spend years focusing on the tools, languages, frameworks, and technical side of things. Then professional work introduces this entirely different layer of understanding people, goals, constraints, and outcomes.
Interesting to hear that a similar pattern exists in marketing as well. Different field, same underlying lesson 😄
I remember went I started my 1st company. One of the first clients I had wanted me to write a php based middleware for his computer line. The list of requests kept coming, and they had only paid the 1st installment. They refused to pay more since I hadn't completed the first part of the job. Scope creep hell and I was trapped in it. It stopped only when I went in and sat them down and spent 8 hours documenting the entire project, and boring them to tears until they agreed to pay me, and at the point though I had a lost a lot of time and money, I realized that I learned something that would save my ass in all future jobs. Before anything is agreed you better have a complete SOW, down to the last t crossed and i dotted. Your friend wasn't exagerating. ;) Good luck!
That sounds painful... but also like one of those lessons you only need to learn once 😭
The thing that stands out to me is how the solution wasn't technical at all. It was clarity.
A younger version of me would have assumed the problem was the code, the requirements, or the implementation.
Instead it was expectations, scope, and shared understanding.
Glad you managed to turn a rough experience into something useful going forward. And yeah, hearing stories like this definitely makes me appreciate good documentation a lot more.
Very well put friend,
One thing my computer networking professor always said was, "Don't be a weenie" - meaning, you can have all the technical skill in the world but if you can't bring that down into the world of people? Of meetings, marketing, social and political dynamics and professional relationships; then we'll never make it as computer scientists.
I have found success in being both a computer scientist and also a budding business-man. In my time at FAANG companies I have learned a lot about the business of technology, and how it is almost more important, or at least more difficult, than the technical in a lot of ways.
A bad businessman won't be supported by even the most impressive technological feats, whereas a good businessman can make a fortune off a product that is only fairly good. And you know who ends up driving more value? The businessman. He has a real product that people use. The weenie has a thing sitting high in a tower of knowledge that will let the dust settle on it.
We love computer science for the science of it, but if we want it to support us financially, we need to don the jackets of business and shake hands with stakeholders.
Thank you Nick!
What stands out to me is that a lot of us start our careers thinking technical skill is the whole game.
Then you gradually discover there are all these other layers: communication, trust, positioning, stakeholder management, understanding what people actually need, and getting alignment around solutions.
I don't think that makes the technical side less important. If anything, it makes me appreciate how much value comes from being able to connect both worlds.
The best people I've met so far seem to be able to understand the technology deeply and explain why it matters to everyone else.
I'm still very early in learning that side of things, but it's been one of the biggest surprises of professional work so far 😄
I have seen how hard and dedicated to the cause you are brother, and also the overthinking part lol, but again that's what pushes us to do better, become better.
Yes coding was never the only skill we needed to polish, I still remember my class 8th English teacher, would go on and on about soft skills, how we present ourselves and how we interact with people which sticks with them for a longer run, and we did stick with our first ever client, afterall he's still keeps in touch with us haha.
I have experienced this, and it really does tests your patience, but thanks to this, I feel like I have grown more and now I can handle clients even better and yes I document everything now. Afterall you gotta learn from your mistakes and work upon them.
Here's to more projects and more growth brother :flex:
Man, looking back, that first client really was a crash course in everything this post talks about 😭
At the time I thought the challenge was going to be building the thing. Turns out understanding requirements, managing expectations, communicating clearly, and not panicking every time something unexpected happened were the real lessons.
And yeah... thank GOD he turned out to be such a great client.
A lot of the stories in this post honestly came from experiences we went through together while building stuff. The wins, the mistakes, the overthinking, the "wait, why is the scope suddenly different?" moments.
Really grateful for all the support over the years, brother. We've both learned a lot since then.
Here's to more projects, fewer scope surprises, and slightly less overthinking (probably not happening) 🚬
Just confrontation with those things and nothing else really. Or you just don't and see how you can be selfsustaineable.
"So true! Whether you're freelancing or navigating a massive tech company, writing code is always just the visible surface of the system. The truly hardcore challenge lies in untangling the logic of human collaboration, managing expectations, and absorbing uncertainty. Technology is an architecture of determinism, but the professional world is a highly complex social system. If you don't compile and run this 'invisible layer' successfully, even the most beautiful code will fail to land. Couldn't agree more!
I think that's exactly what surprised me.
Code is usually the deterministic part. People, expectations, incentives, and communication are where most of the uncertainty lives.
The more experience I get, the more I feel like successful projects depend just as much on navigating that invisible layer as they do on writing good code.
Really liked the way you framed it.
designing outcomes is the new job,
ai can easily write the code
Exactly
I really enjoyed reading your article. Since I am still in school, I have not learned this yet. How do you think I can start to apply this early? I am very bad socializing with new people.
Thank you Tyler!
Honestly, if I could go back and tell student-me one thing, it would be: don't wait until you're "good at socializing" to start talking to people.
You don't have to become the loudest person in the room. Even small things compound:
I was (and still am) pretty introverted myself 😭
The goal isn't to become someone else. It's just to get comfortable communicating your ideas, because that skill ends up helping everywhere.
Thanks for the insight!
Of course! 😄
And honestly, the fact that you're thinking about this while still in school already puts you ahead of where I was.
Good luck on the journey!
soft skills >>>> coding ability recently
You said there is a way to ask tings the right way. What is the right and wrong way to ask things at work?
That's a great question.
I'm definitely still learning this myself, but one thing I've noticed is that the "wrong" way is often asking questions that force the other person to do all the thinking.
For example:
"This doesn't work."
vs
"I expected X to happen, but Y happened instead. I checked A and B already. Am I looking in the right place?"
The second version gives context, shows what you've tried, and makes it much easier for someone to help.
I've also noticed that asking why something exists can be just as important as asking how it works. Sometimes the answer isn't in the code—it's in a business decision, a constraint, or some historical context.
Honestly, I'm still figuring this out as I go, but the people I learn the most from tend to ask questions that create clarity rather than just request answers.
One thing I've learned is that the job isn't just about doing the work. You also need to make your work visible, explain its impact, and sometimes chase other teams or people to keep things moving.
This is something I'm starting to realize too.
I used to think that if I did good work, the work would speak for itself.
But in reality, work often needs context.
People need to understand what was done, why it mattered, what problem it solved, and sometimes even what obstacles were removed along the way.
And yeah 😭 the "chasing people to keep things moving" part was definitely not in any of the programming tutorials I watched growing up.
Saved this for later. The diagram is what sold it for me.
Totally agree. Technical skills are just the foundation. Dealing with people and communication takes far more effort.
Definitely!
very interesting. few days ago i was a cook..now i realise coding is a language. so i use interpreter to make it nicer and elegant. the code.
That's an interesting perspective 😄
I think one thing I've learned recently is that coding really is a language in more ways than one.
Not just communicating with computers, but also communicating intent to future developers, teammates, and even your future self.
The code runs for machines.
The clarity is for humans.
Really enjoyed this. The realization that coding is only part of the job is something many developers learn the hard way. Well written and relatable.
Thank you very much glad you enjoyed it!!