DEV Community

Cover image for I Thought Coding Was The Job
Aryan Choudhary
Aryan Choudhary

Posted on

I Thought Coding Was The Job

The focus on soft skills and communication

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 wanted an app built for some gym equipment he was selling.

To this day, he’s probably one of the most professional people I’ve worked with.

And being the naive amateur I was, I thought the hard part would be building the product.

You know… the actual coding part.

The React Native components.
The backend logic.
The deployment.
The bugs.

That was the “real work” in my head.

Everything else felt secondary.

I was wrong almost immediately.


As the project progressed though, things actually started going surprisingly smoothly.

Which was honestly lucky because life outside the project was kind of falling apart at the same time.

I had just gone through a heartbreak, my final semester was ending, career uncertainty was sitting in the background constantly… and somehow in the middle of all that, I was building this app with my friend @hisukurifu. Really grateful for his support, even today.

nod gif

Looking back, I think having work to focus on genuinely helped me hold myself together during that phase.

And somehow, despite all the chaos, the project itself stayed stable.

The client paid on time.
The scope stayed reasonable.
Communication stayed respectful.

Hell, the guy even paid for renting a Mac because we needed it to build the iOS version and neither of us owned one at the time 😭

At that point, freelancing looked very simple from the outside.

A client needs something.
You build it.
You get paid.
Everybody wins.

Clean. Logical. Straightforward.

At least that’s what Instagram reels and “How I Made $10k Freelancing” YouTube thumbnails had convinced me of.

Reality felt very different.

Because suddenly there were things nobody really talks about when you’re learning development.

Things like:

  • figuring out what the client actually wants
  • discussing timelines
  • dealing with uncertainty
  • deciding pricing
  • revisions
  • feature changes halfway through
  • awkward conversations
  • scope creep
  • waiting for replies
  • wondering if the project will even go through

And honestly?

At the beginning, all of that felt more overwhelming than the code itself.

But slowly, we figured things out as we went.


One thing I still remember is that I never made a written agreement with that client.

Everything was done through pure verbal trust.

And thank GOD he didn’t suddenly increase the scope or disappear halfway through because looking back now… yeah that could’ve gone very badly 😭

Guess some small part of the world is still rainbows and sunshine lol.

But around five months after that project ended, another client opportunity came up.

This time we actually started properly planning things out beforehand.

Discussions.
Requirements.
Agreement drafting.

And then after about a week…

the whole thing just ended abruptly because the project itself was still being aligned internally on their side.

Nobody’s fault honestly.

But that experience finally made something click for me.

I remembered one piece of advice a friend had given me during my freelancing phase:

“You don’t get lucky twice with clients. Make agreements beforehand.”

At the time, that sounded overly serious to me.

Like bro… we’re just building websites 😭

But eventually I understood what they meant.

Because the more I zoomed out on freelancing as a career path, the more I realized I wasn’t just building software.

I was managing:

  • expectations
  • communication
  • trust
  • uncertainty

The code was only one part of the system.

And honestly, that realization changed how I looked at work entirely.


The strange thing is… I thought this problem only existed in freelancing.

Then I entered corporate.

And somehow the exact same realization came back wearing formal clothes.

Before starting my job, I still had this very simplified mental image of software engineering.

I thought:

“Okay, now I’ll finally work in a proper engineering environment.”

Meaning:

  • coding
  • solving technical problems
  • building systems
  • learning architecture

And yes, those things do exist.

But again, there was this whole invisible layer nobody really prepares you for.

Things like:

  • hierarchy
  • communication styles
  • meetings
  • visibility
  • asking questions correctly
  • understanding team dynamics
  • knowing when to speak
  • knowing when not to
  • learning how people actually work together

And once again, I realized:

The technical part was only one layer of the job.


Even learning Japanese started feeling the same way after I began using it professionally.

At first, language learning felt like:

vocabulary + grammar = communication

Simple.

Then workplace conversations arrived and suddenly communication became:

  • timing
  • confidence
  • hierarchy
  • context
  • listening
  • reading atmosphere
  • adapting to people

Different field.

Same realization.


Even marketing ended up teaching me this.

I originally got into it thinking:

“Okay this is probably just posting content and promoting things.”

But behind that was:

  • positioning
  • audience psychology
  • negotiations
  • understanding attention
  • figuring out why some things spread and others don’t

Again, the visible part was tiny compared to everything underneath.


And honestly, I think this pattern exists in almost every career.

From the outside, most professions look simple because we only see the visible output.

Everything is an iceberg.

We see:

  • the deployed app
  • the successful freelancer
  • the polished presentation
  • the fluent speaker
  • the viral post

But we usually don’t see:

  • uncertainty
  • communication
  • failed attempts
  • invisible coordination
  • emotional pressure
  • relationships
  • trust
  • adaptation

The deeper you go into anything, the more human it becomes.

And I think that was the biggest surprise for me.

Not that coding was hard.

But that almost every meaningful thing around coding involved people.


Looking back, I think younger me believed careers were mostly about skills.

Now I think they’re more about people skills.

Technical systems.
Social systems.
Communication systems.
Even emotional systems sometimes.

And honestly? That realization used to overwhelm me a little.

Now I weirdly find it interesting.
Because it makes every field feel deeper than it first appears.


So yeah.
Turns out coding wasn’t “the job.”
It was just the most visible part of it.
And maybe that’s true for a lot more things in life than we realize.


I’m curious now though:

Have any of you had a similar realization after entering a field professionally?

Where the thing you thought was “the main skill” ended up being only a small part of the actual job?

Top comments (85)

Collapse
 
codingwithjiro profile image
Elmar Chavez

"And honestly, I think this pattern exists in almost every career."

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.

Collapse
 
spaceghostctc profile image
FantasmaDelEspacio

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.

Collapse
 
itsugo profile image
Aryan Choudhary

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.

Collapse
 
itsugo profile image
Aryan Choudhary

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.

Collapse
 
rfool profile image
Robert Frunzke

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.

Thread Thread
 
itsugo profile image
Aryan Choudhary

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.

Collapse
 
francistrdev profile image
FrancisTRᴅᴇᴠ (っ◔◡◔)っ • Edited

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!

Collapse
 
itsugo profile image
Aryan Choudhary

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 🙏

Collapse
 
webdeveloperhyper profile image
Web Developer Hyper

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

Collapse
 
itsugo profile image
Aryan Choudhary

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.

Collapse
 
webdeveloperhyper profile image
Web Developer Hyper

Ah! Maybe I need to learn a little marketing to get more attention!🤔

Collapse
 
klem42 profile image
Kirill

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.

Collapse
 
itsugo profile image
Aryan Choudhary

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.

 
itsugo profile image
Aryan Choudhary

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.

Collapse
 
javz profile image
Julien Avezou

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.

Collapse
 
itsugo profile image
Aryan Choudhary

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 🙏

Collapse
 
syedahmershah profile image
Syed Ahmer Shah

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.

Collapse
 
itsugo profile image
Aryan Choudhary

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!

Collapse
 
itskondrat profile image
Mykola Kondratiuk

spent my first year thinking the hard part was technical. wrong. the calls where scope quietly doubled were the ones that actually cost me.

Collapse
 
itsugo profile image
Aryan Choudhary

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

Collapse
 
itskondrat profile image
Mykola Kondratiuk

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.

Thread Thread
 
itsugo profile image
Aryan Choudhary

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 😭

Thread Thread
 
itskondrat profile image
Mykola Kondratiuk

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.

Collapse
 
codingwithjiro profile image
Elmar Chavez

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.

Collapse
 
eljayadobe profile image
Eljay-Adobe

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:

  • the company doesn't care if you work 50, 60, 70, 80, 90+ hours per week; work your solid 40 and go home; if they want you to work overtime during crunch time they'll ask
  • the company does not pay you to code; the company pays you to ship product

I wish I had known those two important things at the beginning of my career. But I learned, eventually.

Collapse
 
itsugo profile image
Aryan Choudhary

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.

Collapse
 
eljayadobe profile image
Eljay-Adobe

Here's one of my replies to an older conversation about working overtime. Fits in with my first point, but with more blah blah.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.