Ask HN: What boosted your confidence as a new programmer?

Realizing that external dependencies are regular codebases just like the one you're working on. That you can open them up in VSCode, look around and figure out any bugs or issues you're having and even open pull requests to improve them.

At that point, you lose the feeling that there are magic things out there that you will never understand and that for the most part everything is just regular old code that regular people wrote.

I'm a self-taught one-man show, and just in the process of onboarding a new, more experienced colleague.

In some ways it's terrifying, as I know a lot of my work is trash.

On the other, recapping everything I've achieved myself, with no CS degree and nothing but Google to guide me has made me feel oddly proud.

From doing the recruitment and chatting to my new colleague, I've really gotten an understanding of how small a role most devs in "serious" set ups have. I've learned a really broad range of skills because I've had to.

There's always going to be more things to learn, but looking back every once in a while can put things in perspective a bit.

As a new programmer? Nothing. Fear of inadequacy was a constant companion.

Over the years, though, as I saw more and more code written by programmers I respect and from companies I respect, I noticed that mine was no worse than theirs -- and I realized that my skills were, at the minimum, just fine. Warts and all.

(Edited to swap "mine" and "theirs" to be what I meant to say)

Shipping and getting to see customers using and enjoying what did not exist before I typed it into being.

A simple CRUD app is magic to the average user, if it does something they haven’t seen done in software before - and that could be as simple as some calcs in a custom domain.

The first customer who tells you “this is great”, if it’s anything like my experience, changes everything.

It also helped that some of my early forays were to clean up code by a guy ten years my senior which was rammed with bugs - fixing those one by one was satisfying and helped me earn trust with my team and in myself.

Everyone you consider "great" at something had mentors who helped them get there. One of the biggest differences between me now, and me when I was new to software engineering, is that now I ask a lot more questions.

When I was new, I was insecure about seeming like I didn't know certain things and wanted to "prove myself", so to speak, so I would keep my head down and try to figure things out for myself.

Over time I've realized that leaning on others with more expertise than you is how you learn and grow, and asking questions and collaborating with others does not reflect poorly on you as an engineer (quite the opposite in fact).

These realizations are what have boosted my confidence - I know that if I'm ever working on something that I don't know how to do, I can go talk to someone who does know and learn something new. If you don't work somewhere where this is possible (i.e. you're always the "smartest guy in the room", as they say) then your growth as an engineer is going to be limited.

For me it was doing nand2tetris.

With just NAND gates and D flip flops as primitives, building a full 16bit ALU, then an ISA for it, an assembler, compiler, operating system (with memory mapped keyboard and screen) and interpreter. Then writing a Sudoku game in that interpreted language, and seeing it reduce all the way to just bits. And then running it on the simulated computer.

Really have a holistic view of what actually happens when I run a computer. Also demystified compilers for me.

Second thing was learning concurrency control, transactions and all that. The Eureka moment for me was understanding that git and databases solve a similar problem. After that, both tools lost their mystery.

Second last but not least, making web apps! A low entry barrier way to make things anyone can use really boosted my confidence.

Last but not least, learning the statistical underpinnings of machine learning.

Of course, I'm still in University so I am by no means an expert at any of the above, but even at my level these things really help with knowing your true place.

I can tell you what limited my confidence as a programmer. It was correctness, or knowing how to deal with stuff so I don't have to check every line of code once I implemented something new that uses the old stuff in a novel way. For some people, it was apparent right away, but I had to discover that once you design something that works in all cases, you don't have to check wether it works as a part of newer code flow, or bigger use case. Only then my confidence started to compound.

In the late 90s to early 2010s it was fashionable to think of code as a graph of dependencies, and as long as you honor those dependencies when changing the code you would be ok. This is simplifying but pernicious POV IMO - reinforced by the zeitgeist that code is truth and comments (in code or otherwise) may not be. This is a cul-de-sac.

Unless developers see things as nouns or verbs, they don't acquire the ability to scale and see the bigger picture, because there is nothing to hold these smaller entities and connections between them (O(entities^2)). The concepts are the bags. Wish someone would explicitly teach us these things, because, sure as hell they didn't teach it in college.

May be people who have a liberal arts background are good at seeing these things, because one of the things they explicitly study is perspective, framing etc. Engineering is quite limited because we don't explicitly study about that.

When you start, you suck. There’s no magical “moment of insight” that suddenly takes you from basically worthless to “vital for the success of the company”. It’s just practice.

For me, I just worked ridiculous hours to compensate for the suckage, read books, listened to podcasts (when that became a thing), programmed at home, read through the code, looked at the code history (code archeology). Eventually you get good and you know you’re good because you can compare your output to those around you.

The secret to surviving the early stage is to recognise that a career is a marathon, not a sprint, and gain joy from the small incremental improvements you make. Everyone above should have worked with plenty of juniors and are just looking for people who are getting better.

When I was finishing my internship at around 19 years old, on the last day a few colleagues did the whole card signing business.

A close colleague - a team lead of a different team who I had worked with a lot, went to a couple dev conventions and meetups with, and agreed with on a many facets of software dev and life in general, signed the card as so:

> It starts with a dream. Don't stop.

Many many years later, I still think about it often. Sometimes, all it takes is a little faith.

If anything, my confidence gets lower as I get more experience. The amount of politics, power jockeying, engineers who hide behind decisions as if they were technical only to be highly personal preferences, how many people reject simplicity and prefer complexity while calling it simple, lack of documentation, etc.

It just all makes me feel like I don't belong in the field. It's all so overwhelming and complicated, and any attempt to try to make something more simple or documented is fruitless if even accepted. People just can't see to be able to wrap the idea around their heads that one thing doing one thing is simple and not "tedious" or "verbose".

The reason why my confidence lowers is that everyone else is seemingly okay with all of this and continuing along the trend. Meanwhile, I feel like I'm just continuing to participate in building giant balls of mud that just barely work and are just barely understandable. So there's an impedance mismatch, and I face it so much, I just have to wonder if it's me, that I'm not smart enough to push through all the cruft or figure things out or just don't understand how to design. Thus, the low confidence. It's just all very confusing.

I would be somewhat suspicious of anyone in software engineering who purports to having figured it all out or having confidence in the field.

Mine happened a long time ago and the industry was very different, but there are echoes of it in some of the other comments here. I'd say, build a project and ship it to customers. The feelings of accomplishment and agency from doing that were a tremendous boost to me. Even though I knew my code was iffy at best.

It's fine if you're collaborating with someone else or a team, as long as there are some good-sized chunks in there that you can point to and say "I did that part." Your customer might only be a different team in your company. The point is that you created something that had an impact on other people.

PS I'd also suggest: Take some time and build something small in assembly language. Getting even a bit of a feeling for how the CPU actually interacts with memory and registers and math and branching will give you a completely different perspective on higher-level languages.

There were two major milestones for me.

One was taking my first college CS course. Just being forced to work in depth with indirection and write algorithms set me up to make all sorts of things, even though I did not go on to get the degree.

The other was to realize, after a few years, that code isn't an edifice - that is, you don't progress through it linearly to a solution, as tends to be the case in school assignments. To solve a production-grade kind of problem, you start by making an incorrect solution that you understand well - the proverbial "start with a hello world". And then you iterate over that to generalize and make it produce more correct answers. The bugs reflect a lack of understanding of the system, and architecture strategies tend to result from knowing that nobody can understand the entire system, thus you design in some constraints and safeguards to enable more complex ideas to build on smaller ones without that understanding.

This process also meant learning to reject "blogpost-driven development", which was a common genre back in the 2000's of people doing some career-making by making a blog about some cute idea they had about best practices. Naive me, I tried testing out every one of them, and eventually, through painstaking reduction, learned that mostly, you have to invent the best practices according to the problem domain. If you can get a direct answer by not writing code, that's a really, really good idea, hence I try to usher more of my work onto paper or into a spreadsheet now.

I have the opposite experience. I always thought I was a good programmer (self taught when I was a kid, then studied in a reputable place where I ranked among the best students). Then I confronted myself with the real world where I feel I'm not special, and that coding is only a small part of what we do. Apart from school or programming contests, we rarely get evaluated purely on our coding abilities, and there's always so much we don't know.

That being said, there are things that boosted my confidence, such as getting offers from FAANG. But it was temporary. Software engineering still seems like a tedious and hard activity. And it's getting worse now that everything is distributed.

I can't speak for myself (it's been too long and I'm self-taught so I was already fairly confident at my first job), but a former co-worker did have an interesting insight at one point:

They came straight from a bootcamp and for months felt like they weren't getting better, were constantly asking questions about stuff. It only finally clicked and they gained confidence when we got a second out-of-bootcamp developer and the first person was the one that was constantly answering their questions. They hadn't realized how much they were learning because their only comparison had been those of us who had been there a lot longer.

Reading textbooks.

Using a REPL-based language like Lisp (which I learned from reading advanced Lisp textbooks) for several years before I worked professionally as a programmer enabled me to dive into complex, underexplored parts of the (Python, C) projects at my first job, which meant I basically owned some very important parts of the stack.

Reading and applying ideas from Unix sysadmin books enabled me to be comfortable jumping around the OS very quickly, giving me a speed advantage even when the computer I used was pretty underpowered, relative to my colleagues, early in my first job.

Build, build, build, and build some more, then build, oh and you should build more.

It's taking on a challenge big or small and seeing it through no matter what it takes. You'll get stuck for hours, days, sometimes weeks, you'll get frustrated, tired, annoyed, but you just refuse to give up and eventually get it done.

Those are the moments that bolster your confidence and you realize you are capable of achieving seemingly impossible things.

That confidence of "sure I can figure it out" is what you need to feed and grow as a programmer and probably in many other professions.

Best way imo is to pick reasonable small contained projects, and slowly ramp up and take on bigger challenges. If you take on too much, shelve it, do something smaller, then return to it later.

It takes a lot of time, effort and perseverance, but as long as you keep going you'll get there in the end.

Deploying my pet project on a Linux virtual server.

At that time I worked with some enterprise software on Windows, and any particular setup was so fragile, that it caused anxiety to touch anything and learned helplessness preventing experimentation. It didn't help that built-in diagnostic tools on Windows in the XP era were virtually non-existent.

Linux VMs in contrast were (and are) disposable, have all their guts exposed, and CLI is your only way of doing things. You're welcome to experiment, and basically forced to automate.

The best hackers I saw learned some turing complete system when they were children without having been taught the concept of programming. I guess for them "take the first step from being a tinkerer to being a skilled craftman" was when they learned that there is a whole field of study for bending those turing complete systems to your will. Then they spend like one day or week binge reading a programming book and understand all of it, because they solved much weirder and harder systems for fun.

The biggest confidence boost as a new programmer was the first time I wrote some software on my own, other people used it, it worked, and they liked it. This happened within about a year of starting out. I suggest everyone try to build products and give them to people. Nothing more validating to me than building stuff people want.

The attitude of my bosses. In two separate jobs, when first starting out I worked on some simple projects that led me to 'fixing' some other problem I encountered. Both times that problem was well solved in some other way I was ignorant of, but they gave me a "well done" and didn't make me feel silly for being proud of my 'fix'.

I was just learning the relevant languages and jobs, so their response gave me confidence to keep trying things and learning.

For me it was reviewing code and seeing a ton of diffs - to help realize the incremental change nature of coding and seeing small pieces of code in relative isolation

"How did you gain this confidence to take the first step from being a tinkerer to being a skilled craftman?"

By completing stuff. Making things that actually work in the real world.

(and my problem in hindsight was rather overconfidence, just because I made some small games and websites, I considered myself already to be a programming master)

I was a self-taught guy largely working by myself. I went to some big Microsoft education conference and met other people and realized most of them weren’t smarter than me or doing something much more complicated.

1. Being able to take a problem, break it down into progressively smaller chunks and methodically work through it. This often looks like binary search (eg. When trying to understand how a codebase works or debug an incident). 2. Being able to decide what detail is unimportant and what’s worth focusing on to work on whatever the current goal is.

3. Being able to use version control. Having the confidence that my work cannot be lost was a big boost.

4. Having some understanding of what non-developer stakeholders care about.

My first programming language is JavaScript back when it only lived in the browser. The compile target of the browser is, and always has been, the DOM. The DOM is a tree model. When I learned to appreciate that in my first year of programming everything became simple. Even before JavaScript became fast you could do most things with relatively high performance easily cross browser once you achieved that solid foundation. No frameworks, no unnecessary abstraction libraries for vanity, no bullshit.

It was over 12 years ago now... but before then, I'd only taken up programming as a hobby. I was addicted to gaming and computers during my high school years, either playing a game or coding something.

Went away to college for something completely different, psychology, but when I got home and started applying for jobs, nobody would hire someone with a bachelors in science only.. so I decided to pull out an old trick of mine: I would apply to the programming companies too. Got an interview. Got the job. Even though my math skills were horrendous.

The confidence in my programming skills came a few months after they hired me. Til then, I'd been working on building various little programs that had no real purpose. A ping pong came, a slot machine, etc. My tyrant boss had me go through training to use various functions in Visual Basic 6. Some of the most valuable ones were using arrays and collections, which had helped me understand databases later on when I was learning PHP.

I was developing software for an autobody shop. I really couldn't wait to work "in the main program" but once it was established that I was ready, that's when the confidence started taking off.

About 6 months later, his customer base went from a few hundred to a few thousand. My job was to focus on the UI, making it more user-friendly and easier to use and fix existing bugs in the program. I loved and hated that time of my life because it led me to meet a wonderful woman, yet I was going through hell everyday for that tyrant. Fortunately, I took what he taught me and used it to further establish my career elsewhere.

After my first internship as an AngularJS developer, I joined a small team that built some pretty cool stuff. Very interesting stack, lots of programming languages, different databases, queues, etc.

I joined as the "person who will teach them how to use AngularJS and rewrite the Ember app with it". This went pretty well as we (mainly myself) rewrote the app pretty quickly after months of them struggling with Ember (I didn't use Ember, so I don't know if Ember was so confusing or they were just lazy to learn it will).

After that, I started looking into the backend and I was able to contribute to the company's success. When I had to use Cassandra, Kafka, Symfony, Ruby, Puppet, etc, I'd watch hours and hours of videos, read documentations until I knew it "well enough".

After some time, I noticed that quite often I knew the subject better than my colleagues and I could come up with solutions and implement then on my own.

This helped me realize that these technologies can be learned and it's only a matter of determination, dedication and patience.

You can't break anything. It's still true (in like 99.9999% of cases) so just go ham. Try, try, try, try. Nothing bad can happen. This was very helpful back then for me. Not sure whether it's still helpful but back then this was on a computer my parents smuggled into the country...

I was smiling reading git here -- the above happened before CVS was invented. I am old.

A programmer's confidence can come from a few different directions.

The chief one, I think, comes from simply having achieved enough challenging problems to the point where one knows that, even if their solution isn't perfect, they can figure out basically anything. The overwhelming majority of programmers can get to this point eventually.

Confidence also comes from the eventual realization that, with few exceptions, the majority of programmers you think are "better" than you are really aren't objectively better. They may have a fancier title, a bunch of GitHub stars, have given presentations, or maybe they've written a book, but this doesn't mean they are a better programmer than you. It might be hard to understand as a novice, because virtually every novice is going to feel inferior for lack of experience. After having gained sufficient experience, to the point where there's seemingly no problem one can't solve, it may become obvious that these programmers one once viewed as elites actually just broadcast their craft in a way that gives them higher authority; I stopped viewing most programmers as being better or worse than each other because I've witnessed enough problems caused by the clever solutions of senior and staff developers. It's just much easier to blame a junior engineer's solution when it doesn't work out. This isn't to say that more seasoned programmers aren't worth their salt, but there's almost never something they have that you can't have, and every programmer out there writes bugs all the time!

And finally, seeing the tech hype come and go over a long enough period of time can eventually bring one to the point where they look back on methodologies, frameworks, and design patterns they were once introduced to and come up with the original thought of "You know, I think that X was kinda bullshit to begin with." I think it's really unlikely that a programmer can have a 20+ year career (or even a 10+ one for that matter) and not come to some conclusions like that. Though it's easy for a novice to get caught up in the churn thinking they've got to learn all the things and feel inferior for not knowing it all, experience may someday teach the programmer that most of the churn was hype and that their own ideas on how to program effectively probably would have worked just fine.

I would say that I gained my confidence by just trying enough times and gaining experience.

I am still a novice programmer, if you call a recent graduate that.

I feel stupid all the time. I don't know anything about almost everything, and the little I do know about, I'm sure it's less than what I think it is.

I don't know how a GAN works. I haven't the faintest clue about machine learning. Someone asked me 'hey, you have a CS degree, tell me how ChatGPT works.' I couldn't answer that.

I never took databases in university either. I am mediocre at algorithms—it takes me 45 minutes to an hour to solve a supposedly 'easy' problem on LeetCode.

I still use Windows and Visual Studio, because that's what I grew up on. I don't know how to use Vim besides hjkl and :wq!.

I don't know HTML and CSS. I've looked at the more popular blog posts in the recent Ask HN thread. Everyone discusses things I've never even thought about. They have custom blog engines they wrote from scratch, that actually work.

I know a tiny bit about computer graphics, but I have hardly written any shaders. I also know an equally inconsequential amount about parallel computing, and even so, I dislike any problem that cannot be easily and embarrassingly parallelised because I don't fully get synchronisation and acquire-release semantics.

I don't know if anything can boost my confidence at all. I have a tendency to ingratiate myself with people a lot smarter than me, and as a result the large majority of my friends from university are now working at HFTs earning five digits a month.

While I certainly have learnt much from all of them, they just makes me feel even more stupid—through no fault of their own, mark my words.

Not sure if this will ever go away, but I believe the feeling of stupidity will only ever increase as I realise just how much I don't know.

Getting my code to work for the first time (early 2000s.)

Starting out with intranet PHP was a daunting task, had to get the system setup (Apache, PHP, MySQL) write the code then mess with permissions, etc. Getting that first response back that it worked (or at least kinda worked) said to me you can do this!

back when I learned BASIC 20+ years before that, was the same thing, Back then, I started by either entering or loading a simple program and changed stuff and realized I can change this and the silly experiments in changing values and commands gave me more encouragement to learn and try more.

Early success even if stupid, is big positive reinforcement. If you can't get to Hello World because you are stuck in language/IDE configuration, you aren't going to get fer. If you can get there quick and realize the potential you now have - all that low end stuff becomes a desired necessity to make your magic happen.

It was sometime around 1994 and I had working as a UNIX sysadmin / systems programmer for the college of engineering for about a year, while studying computer science. Most of what I was doing involved scary stuff like TCP/IP, other forms of IPC, terminals, permissions, filesystem quota management, etc. I often lacked confidence that I was doing it right.

Then one day I was at the book store and stumbled upon W. Richard Stevens Advanced Programming in the UNIX Environment. I spent hours reading it while sitting on the floor right in front of the empty spot on the store’s bookshelf. It taught me that much of why I was doing was right and helped fill in a bunch of gaps. A couple weeks later I was back with half a week’s pay to take it home with me.

Switching to statically typed languages (vb.net/c#) combined with a powerful IDE. Suddenly the IDE was helping me progress, embedding the documentation straight into my typing (through auto-complete and hint boxes), showing all the alternative fields and methods (self discoverability of APIs), calling out my bad code practices, allowed me to refactor the code without breaking things.

Which is why I am not sure I agree with the view that dynamic languages are good for beginners, I think beginners need a third wheel, an IDE that understands your code and can tell you with confidence that you can't do "a+b" in this context. For that it needs to know what a and b are.

My first full stack app. Didn't need to be complex, but it worked.

For me the moment was a year or so into my first programming job, this was in the 90s. We were debugging some device driver issues and found that we'd made bad assumptions about the order in which things happened between our interrupt handlers, device driver thread and application threads. Once I took the time really mapping out what all can happen in an asynchronous environment and then setting up long-running stress test with multiple clients it clicked in place that you really have to continuously test your mental model against what could happen in the real world.

Fixing bugs in open source software, instead of reporting it and letting the maintainers fix it when they're able. Doing that helped me understand how to quickly familiarize myself with a code base, gave me confidence that my code is also good, and helped me have a higher development velocity by not waiting on a third-party for a fix.

For personal development, it was merely shipping things. The more I published, the better I felt about myself. The more I published, the more I had learned and had to refer to. Now when I'm taking on tasks I can instantly recall how each of the pieces of the problem can be stitched together from things I did previously (or at least know where to look for foundations to build from)

For the confidence? It was working with others. The first job I had I got to sit down with one of the company's programmers as part of my on boarding and watch him work through tickets. After I saw just how flawed everyone was I felt a lot better about myself. I suppose that's a weird thing to say: Oh he was pretty shit, so I shouldn't feel bad about my poor performance...but that's not the point I want to make really. More that, it is wrong to compare your efforts to learn and grow against the final product of others. Once you sit down with the experienced devs and see how they shape and form the product and all the bumps along the way it doesn't feel so bad to struggle on your own.

Ultimately the skills that I honed that gave me the best boost in confidence were not really the direct programming parts where I put letters and numbers in files. It is the debugging. Understanding how things move and where to look for problems makes me feel like I can solve any problem with the right tools.

What seemed to help me was learning how to test things so I didn’t break the build.

This helped me because I had to learn requirements, talk with people, understand dependencies, and not make people’s life harder. And I had sort of a value to smart seniors as I would maintain stuff that was hairy to change and not break it.

I also spent a lot of time on nights and weekends volunteering with the network people and hardware people and firewall people to understand how those components fit into the architecture.

Mh, I'm not new anymore, but there is one thing that's a huge confidence booster.

Someone coming around with a pull request going "Heyjo. I needed new X in your project. And, I looked at it and X and tests for X just slotted right in there. Can you take a quick look if that's right?"

I consider these easily and obviously extensible workhorse code bases my best work, even if after a certain point, I may have built like 10% of the thing and shouldn't consider it my thing anymore.

There wasn't one thing that gave me confidence, it was more like a series of little things. First is when I could look at code and understand most of what it was doing. When I was first starting that was a milestone achievement. Eventually that faded and I got confidence from being able to interpret stack traces and error messages. Then getting code to run without errors, then knowing how to throw a script together without having to consult any documentation.

The first time I took a rather complex library, learned it inside and out. I read documentation, did examples, wrote my own examples, implemented quick and dirty working versions, refactored, sometimes started again from scratch and eventually clicked with the material. It started slow, but once I really began to understand things, the code started to write itself quicker and quicker until I had stable production code that I’ve been maintaining for several years now. The beginning stages was like solving a big puzzle and built a lot of confidence.

Also in school we had to do some big projects like make a virtual machine from scratch and implement things likes call stacks, threading and memory management with our machine op codes. Doing a big long project that really pushes you out of your comfort zone is a BIG help and also can be an opportunity to do something really fun.

Edit: I left out the important role of asking questions, talking with others and even taking the time to compose a forum post or issue on github when it seems that I’ve truly exhausted all my options. Bottom line is, when I took my time and really tried my best to learn something new/difficult there was always an eventual breakthrough and consequential boost in confidence

for me it was (and still is, especially when i learn something new) successfully solving problems. for a novice that means breaking tasks down so that they can be solved in small steps, each step giving the feeling of success and motivating you to go on. it is frustrating to spend a week hunting a problem without making any progress. for a novice that can be crushing their confidence, especially if they get the impression that it their fault that it takes so long.

books or classes didn't do anything for me until i was able to actually apply the new things learned. (for me learning is problem oriented, i take a problem and learn how to solve it)

also as a novice i found building a project from scratch daunting, because there is so much stuff to do before you can get to have some actual functionality. i prefer either to start with something very small but with some usable functionality that doesn't take long to build, and then add features until it is completed, or take something already working, and build upon that.

when i learned lisp i took the example project that was in the book towards the end and built it into the tool i wanted.

though i think test driven development can help here too. as each passing test is a success. so write a test, pass it, continue, until you have something working.

Humanising wizards.

Even the most incredible 10x engineer has at some point done the stupidest thing you can imagine: deleted a prod database, set a server on fire, pushed that one simple single line fix that took down several downstream services, and so on.

Those stories and learnings are the ones that turned the stubble-chinned doe-eyed juniors of yore into the full-bearded crusty Gandalfs we love, that seem to know everything and solve problems in a finger snap.

Shipping.

Seriously, getting your code out there into the hands of users is the #1 confidence booster for all developers, everywhere.

There is no better feeling than to see the completion of a unit of exchange between the compiler and the end-user.

Another thing I do, is read, read, read. I have tens of thousands of repositories that I've checked out and had a good read of, over the decades. This is an extraordinary way of learning new things and gaining competency.

Realizing that 99.9% of the bugs I will find I can solve by myself. Really, just work the problem a little bit at a time. How many times have you found a bug that you absolutely couldn’t figure out? Scant times most likely.

Now, the other side of that coin is realizing that, yes, I’ll eventually figure it out, but some of them will just be absolute misery to work through ;)

But eventually you emerge on the other side and you move on.

Writing (parts of) an operating system, networking stack, interpreter, and text editor. It dispels all the magic.

Getting over the whole idea of beautiful or perfect code. Realizing that code is a medium of expression and that there is no single right way to do everything. Beginning to think of code as a clay-like medium rather than literary prose that needs to be beautiful like a cathedral.

Seeing how some of the most experienced and productive programmers do things in extremely simple straightforward ways, with no unnecessary cleverness, indirection, abstraction, or anything like that.

Seeing how linus torvalds is right. It's really all about the data structures. Once I understand the data structures and their relationships, I can understand any system. Dispelling the myth that some things are just "too complicated". Almost every problem or system I've ever come across can be reduced to a page of data structures.

Realizing the power of fast feedback loops. How just about any requirement or problem can be expressed as a test case. And that once you have the test case you can fix anything.

First week on the job during new software engineer training I asked the architect of our RTOS what ended up being a silly question and he gave me a patient answer in front of my peers explaining why it worked that way currently and the challenges doing it differently.

About four years after he reviewed a series of changes me and two coworkers put together to rework this handling.

Realise it doesn't work the first time for most people. Even really good people.

Also for me (very specific to people starting in late 90s) realising I wasn't the only person that thought forced 'object oriented' programming was bullshit. 25 years later this style has gone out of trend, and a lot of people realise that Alan Kay meant something more like the actor model than Java.

What boosted my confidence as a new programmer was celebrating small victories and milestones. Completing my first project, solving challenging coding problems, and receiving positive feedback from colleagues or mentors gave me a sense of accomplishment and reassurance that I was on the right path.

For me it was when I was able to complete a task that involved a lot of pieces outside of my normal daily flow.

I started as a full stack co-op, but 95% of the work was React. Then we wanted to implement Cypress to do fully E2E testing.

That led my to dig into CI (Circle), Docker, AWS, Redshift, Security Groups, networking. To make the test truly end-to-end, we had to spin up about a dozen containers, several databases, connect to Redshift. All those things were very, very strange to me and very scary.

Luckily nobody wanted to touch those things, so the task was up for grabs and my manager allowed my to try (since I was a co-op, there was not a lot of pressure to deliver other projects).

When I was done I realized that I was not just a JS/React dev, but I could dig in to other complex things and figure them out. My confidence shot through the roof and after that I wanted to work on all big projects available. Ended up switching to a backend team that does completely different tasks from my original one.

I was 12-13 at the time. When I started programming it seemed really difficult. I didn't have access to the Internet back then.

But I saw it like me against the machine. Since I was youn I wanted to be an inventor. This tool allowed anyone to "invent" any software coming out of the inventor's imagination. It just required a computer, and the inventor not giving up and using his brain. I could do that. I liked the challenge.

Be a tinkerer, have fun! Discover things on your own. Dare to be stupid and do whatever stupid thing feels right. You don't need to follow some pre-programmed plan.

Programming is all about problem solving. You solve one problem, good. Now you will have another problem. No one guarantees you will solve it nor how much effort it will require specifically for you to solve it. And maybe it's the wrong problem to solve. But you will end up figuring all that out, and then you will feel accomplished and willingly hunt the next problem.

Both in programming 10+ years ago and in painting ~2 years ago did the same way; I didn't need "confidence" since for long time initially I was just playing.

Follow a bit some tutorials, then play around with code, try to make something, its ugly AF so keep trying until it's no longer horrible. Rinse and repeat.

How to know when you are "a skilled craftman"? As long as you look back 6~12 months and think "that was ugly! I'd do it differently today" you are learning (good!). Otherwise you have become a skilled craftman (also good!) or are stuck, but at least in my case it was obvious when I was actually stuck and not improving.

Note: this "playful learning" didn't work for me with learning a language (prob need a base good enough to just keep the ball rolling) nor with piano (probably because painting is satisfactory from the first stroke, but piano is only after you can actually play stuff).

When I sold my first startup. Writing better code always helps, but code that works is good enough.

I panicked before my first job. It was in .NET and I bought a couple of large books about the subject and read them. Then to get on the job and eventually realize a lot of the other people were hacks who didn't understand the technology they were working with.

Under confidence is extremely rare in new and inexperienced coders.

For me, what really boosted my confidence long term was getting yelled at by people who actually knew what they were doing because I sure didn’t. But that ended up being more of a bathtub curve of confidence.

I was officially employed as a help-desk tech while I was going to school for CS. I wrote some internal-only software we used to track all of the installed software on all the hosts in our network and catalog them to a database. This was in 2000, so there weren't very many software packages that you could run like that would crawl the entire org and catalog the software installed without installing an agent on people's systems. This worked that way, and my VP came and asked me to help a team package it up so we could sell it as another product from my company. Looking back, what I wrote was crap, but boy was that a boost in the breeches, if you know what I mean.

CS50. Things I'd always heard about and been intimidated by -- C programming, videogame programming -- pops up in the whirlwind curriculum. They're really trying to teach you that "it's all just code, and you can learn anything."

It was while I was taking CS50 online that a programmer left the company where I'd been working (in a non-technical position). His manager was scrambling to re-distribute his workload, and knew that I'd started taking an online CS class. When he offered me some easy entry-level work, I'm sure I would've said "no" just months before. That was the exact moment when the class made a huge difference.

Shipping to large numbers of users in production, getting the metrics back, investigating alerts / bug reports, finding edge cases in real data, and solving them.

Now I have a handle on the sorts of things that can go wrong / are going wrong in the real world, some earned confidence in my ability to fix them, and general upward trend in my ability to anticipate and prevent them during development. On the other hand I no longer have any trust at all in code that has not been put through real-world usage or where I don't have access to feedback from real-world usage. Reality is much better at generating interesting test cases then we are.

I was working with a decoder for the LD-CELP voice compression algorithm. The machine it was running on was compute-bound and the playback stuttered a lot. I dug into the code, then went to the papers describing the algorithm, then went back into the code and modified a piece of it to be better tuned to the data I was processing. In the average case I probably made the code worse, but in my specific case I sped up the thing by 30x. That gave me confidence in a few things:

1) I can figure out issues in other people's implementations.

2) The best solution may not be the best solution for you, and my hunches on optimization might be correct

3) It's fun to look like a wizard to your peers

For me it was working in a company that had a process.

My first job as a programmer I was tasked with building a replacement for an existing system. I worked by myself, and was just told to ask if I had any questions. I reported progress once a week by giving a percentage complete- for the whole project. That’s it.

The next job I was supposed to be a consultant. But I was so clueless- I didn’t know what I didn’t know. Eventually I was canned.

Finally The got somewhere that had a defined agile process- I started getting work done and was even able to mentor some people. Then I flourished and now I’m pretty comfortable with where I’m at.

If it’s not going right, the position might not be a good fit.

My perspective is different than what has been posted, so here it goes.

I knew I could outwork everyone and brute force being a better programmer by a function of continuous improvement through hours of work. (btw I was wrong, there is always someone out there that will outwork you...and they will be smarter than you, but hey it made sense to me).

I didn't realize I made it until

a) People would recognize me in meetings because of my code

b) New programmers started to ask me for advice

...now I'm in the Sr Devs, Tech Leads, and Lead Architects ask me for advice level. Honestly, I still have the same attitude, if I work effectively, I can keep getting better. Notice that I remove the "work harder" part.

Becomming an old programmer.

Sounds like a joke but really, I felt super green until suddenly I didn’t. I didn’t really figure anything specific out, I’ve just now seen enough problems that I am confident I can work through whatever I run into.

I gained confidence by making things. Whatever you think is cool is a great place to get traction—for me it was games. 3D accelerators had recently become GPUs, and I loved the idea of programmable shaders. I read the Direct3D 8 documentation cover to cover and I got into writing a little game engine, including shaders for the ATI card I had at the time. I never shipped a game, but that wasn't the point for me. It felt great to see that I could figure out some of the acknowledged hard parts of our field if I followed my interests and put in the time to study and play.

Implementing things that I thought only 'smart people' can do and seeing that there's really nothing mystical about it, and if you're willing to read and hack around long enough you can understand it.

Few notable things were the first time writing a ray tracer and seeing it work, writing a small emulator, writing a lisp etc. A lot of low level stuff. Learning what executables are made of on different operating systems, and so on. When you're going from not really understanding half of the stuff you use to building some of it from the bottom up, that was very valuable to me.

Any shred of imposter syndrome disappeared when I looked at the corporate code bases for the first time and realized that they didn't do magic, but things I could understand. I read the software and the documentation and it made sense. Talking to the developers of that software made it clear they worked long and hard on it and naturally knew more about it. This familarity and the decade(s) of experience was the only difference between me and them.

Also realizing that a lot of people write really not all that good software was another big point.

I started in the dirtiest ugliest codebase imaginable. I worked on a MUD descended from DikuMUD (and originally written by native danish speakers). Seeing code that ugly that worked and making it better, faster and more readable gave me the confidence that I can make a significant impact. Moving into the professional world I found that corners are constantly cut and I can always clean up shoddy implementations and make them cleaner. I've gone on to be a developer, data architect, lead and manager and it's always great to find new experiences.

When I fully understood that impressive code that I was reading online was written by a real person, and that as a fellow real person, I should be able to learn to understand and write similar code. I experienced this when I was doing DailyProgrammer challenges from Reddit in highschool. I was doing most of my programming in Java at the time, but much of the Java solutions that I saw were using Java 8 features that looked alien to me. Realizing that it was not alien, and would just take time to learn, was a massive confidence boost for me for some reason.

My imposter syndrome basically disappeared when I started onboarding newer coworkers.

It exposed me to _other_ people’s knowledge gaps, and made me realize how many things I actually knew and understood.

I just worked through making a 2D physics engine via Gustavo Pezzi's course on pikuma.com

Seeing shapes collide, bounce, roll, and understand exactly what was happening in the code I wrote was a huge confidence booster.

Creating actual things. Just reading books or watching videos or reviewing course content isn't going to do that for you.

Start on real projects as soon as humanly possible, even if they're junk to begin with.

Building, releasing and supporting your own app.

We don’t let junior devs do this now because programs are huge. We throw junior devs into bug fixes on large existing code bases (which are often not well architected, full of tech debt, etc)

There needs to be a step between the toy projects in college courses and the million+ line code bases.

Building, releasing and supporting small apps successfully, interacting with users, making changes they want and actually delighting them gave me a huge confidence boost in my early career.

We do a disservice to junior devs now.

My main confidence boost was a senior developer that answered every question even if it was the most stupid one that you could imagine. He would sit down and explaine it to you like you were three years old. Sometimes he at first would say to look for solution by yourselfe or just give you a hint that was enoughe to figure it out by yourselfe.

At the first company that I worked for I quit after a week because everyone took a task and worked for themselfe. None developer had time to explaine something to you and no documentation.

Building a really simple LISP interpreter. I had a few years of tinkering under my belt. One day I came home from school after reading, SICP, I think. I sat down at the computer and hacked together a little LISP interpreter in less than an hour. I was stunned. Then I realized that I too could make programming languages, and that programming languages were just tools other (really smart!) people had put together, and that I could understand them.

Also, learning Git was incredible to my confidence in modifying code.

Another programmer showed me what he was working on. He tried to implement a driver for some badly documented virtual hardware, but couldn’t figure out, why the set of bytes he used didn’t work. I knew about big and little endian and suggested to simply turn the order of the bytes around. It worked immediately and I had solved a problem that had him puzzled for some days. This gave me confidence that despite my little coding experience at that time I could still make a positive impact.

Launching the first somewhat useful product that I had worked on very nearly from the ground up, as part of a real team including people who actually knew what they were doing. In hindsight, my contributions were more trivial and janky than I thought at the time, but nevertheless they were in there, in a non trivial working product. It showed me that it's not magic, it's actually possible to build things and make them work.

I'd been programming as a hobby for years, but I got my first internship at 20 years old and asked one of my first managers a pretty basic question about what I was working on, and instead of telling me what he wanted me to do he said "whatever you prefer, I trust your judgment". That one sentence didn't cost him a lot to say and I'm sure he didn't even remember it the next day, but it meant an awful lot to me.

I taught myself to code in high-school, entering my first job was daunting but I remember just sitting back and absorbing information like a sponge. Obviously I came in with some fundamental knowledge and I was working with a language I had been using personally for years but if I had any advice for someone who's new it's to just sit back and learn as much as you can. Nothing wrong with it in my opinion.

As a novice programmer, getting my runescape guild mining bot to keep working longer than a day was the first step, and possibly still my greatest achievement.

For me it was more like the opposite, over time my confidence turned into wisdom, empathy and experience; I feel like confidence is was more of a prerequisite.

The ability to use the debugger for troubleshooting any unfamiliar code has drastically increased my confidence. Unfortunately I was not taught to use such tools while at university where we used to code on a daily basis.

Also, using state of the art IDEs to be able to navigate between my own and third-party code removed pretty much all of my anxiety when dealing with code in general.

For me it was migrating the unit tests for a whole project from JUnit 4 to 5. Reading and understanding the code, transforming it into a newer version of the framework and doing some cleanup / optimization while at it was proof to me that my skills were also applicable to "large", "real" projects.

Always had imposter syndrome. Built out Infrastructure as Code for our company from scratch, with tight security policies and a lot of separation between resources, which got a lot of flak from other, more experienced engineers. One of the access key sets we share with customers leaked Monday, and due to how those rules are built, the attackers couldn't get anything. Felt pretty OK after that !

Because I desperately wanted to create something, and because programming is, gloriously, the only black and white part of my life. I can make something work once, and know it will keep working. It’s under my control. Love that. Always have.

What boosted my confidence as a new programmer?

1) Ignorance. Knowing just enough to be dangerous was great against analysis-paralysis.

2) Positive feedback from clients. Clients didn't care about my spaghetti code. All they saw was a solution to their problem. That was very rewarding and made me confident. Well, at least until a senior dev took a look at my code and rightfully destroyed my confidence with not-so-polite suggestions.

You might need the equivalence of a solo flight for a student pilot. You fly 3 take offs and landings by yourself as a confidence building step.

1. Stars on GitHub 2. Writing a library (I used to think those were magic) 3. People opening pull requests in your open source repository

Something that weirdly helped me was watching live programming (not tutorials) of good engineers where they try and tinker - an example is geohot's 5 hour stints on YT.

It made me realise that good engineers don't have any mysterious unknown tool or advantage, they're just relentless researchers when trying to solve their problem (i.e. using Google, Wikipedia, API docs)

I dialed in crazy on one single component of a large Open Source project, and at some point......I was the expert. I didn't understand everything in the project, and I didn't know near as much as most people, but for one tiny component, I couldn't find someone to answer my questions on and I became the one people went to for questions.

It kind of puts into perspective how software works.

Funnily enough, getting bugged by some random people about a bug in one of my projects. I'd built projects before, mostly for the fun of making them, and occasionally for my own use. The first time someone reached out to me on Discord going "Hey, love your tool, but this feature hangs my machine" was a wake-up call that I had actually succeeded in making something useful.

Some people like to appear self-made, but honestly college is what did it for me. I did tons of side projects and worked as a part-time SWE while in college. Still needed the full foundation to be confident in arbitrary tasks. I could get through my work without it, but it was narrow experience, and self-tutoring is harder / less reliable than anyone will make it look.

Not a junior programmer for a couple of decades but of course I still venture into new areas and feel junior! Have to say that Chat GPT gives me a lot of confidence. I can ask it questions, bounce ideas off of it and get it to validate my thinking, design and code before shareing with anyone else. Confidence and overall anxiety has really improved in the last few months.

Learning to decompile and debug third party libraries was really handy. This was back when a lot less stuff was open source, so debugging threading issues in BEA Weblogic “enterprise” Java was really helpful to learn about packages and libraries and also understand that other people’s code isn’t magic, it’s just some other person like me doing their best.

I think it's healthy to consider yourself tinkerer even when you have a lot of experience.

People who believe they are skilled can fuck shit up on a much bigger scale because they are a bit too confident. In reality, almost all code is crap. Understanding in what way your code is crap is healthy and useful. Believing that your code is good is not healthy.

When I was starting out, I worked closely with another dev on fixing issues that impacted customers of our product directly.

When you see your code in action in the real world and know the impact it can have, you gain a new respect for developers who are conscientious about their work, and also that software exists to make something else function.

I guess that would have been the first time I build something that could do something useful (to other people) that wasn't possible before, the first time I made something that could exist exist.

For me that was when I crossed the line between merely tinkering and actually crafting something that could stand on its own.

Time. There was no silver bullet and it just took time building lots of different things at different levels of the stack.

Finding that everyone else was fumbling around and googling answers just as much as I was. Also, the first time I saw a big production code base for what I thought was high-level project and seeing how messy it was. Instead of feeling like I was actually good enough, I felt like nobody was actually that much better than me.

>What boosted your confidence as a new programmer?

That you don't have to know everything and if you're dealing with legit people, they'll be totally find with that and even expect it.

Trying to lie and say you know everything or say you're a 9/10 on every other odd skill/language will put you into a terrible place.

When I wrote my first code that entered production and saw that it worked and produced value for my company, that's when I gained my first real confidence in my craft. And this still holds true, every time I put code into production that works flawlessly and is properly tested it gives me a boost.

When experienced developers/colleagues started to use tools I created as part of their workflows. Occasionally they'd submit PRs demonstrating more efficient solutions, which helped me enormously, but overall the tools remained untouched.

It was also a great reminder that "good enough" is just that.

First real programming lesson was tic-tac-toe. I figured out a more efficient logic flow than the one proposed by the teacher.

More recently: Realising that the two senior guys who had been there for 20 years had basically created an incomprehensible clown car of spaghetti code that not even they understood.

Working on teams with great functional test coverage, so it's difficult to accidentally break something big. The mindset that if someone makes a mistake and introduces a bug, it's not their fault, it's the tooling/process's fault has stuck with me throughout my career.

Working with people and getting feedback. Initially code reviews have many comments, then slowly less and less, then you start reviewing others, finding the same issues you used to have.

Eventually you get enough general knowledge to pick up almost anything and figure it out.

The confidence really came when I deployed my first few medium-to-large features to production. Positive user feedback, few errors in production and good measured performance made me proud of my work, that’s when I realized that I’m going to be just fine!

Shipping to end user. Even if it's a script to rename photos from exif.

There is no glorious or inglorious software. As long as it benefits users it's good.

Good quality code will come naturally as you will be faced to complicated problems.

Also, do not be scared to write things from scratch.

There is no perfection on the first try. Perfection is the iteration you put over time. That's what I learnt in my years learning programming. You just have to put effort in it, and constantly being eager to learn more.

Making something _actually useful_. Creating a to-do app teaches me how to use tools, creating a web scraper that sent me an email when clothing my wife missed the chance to buy was back in stock filled me with confidence.

The best confidence boost is when someone uses your software and talks about it! Happened to me when I was young and programmed a game at school on a calculator and everyone wanted it, sent via link cable :)

Doing meaty projects that were a little out of my comfort zone. Sometimes, I'll go back to old projects and write all the ways I'd refactor them (even if I don't actually refactor it).

Ship something. This is part of what continues to hold confidence too. If you are consistently getting things built and shipped, it shows you are contributing. That's what it's all about.

Looking at "professional" projects.

There is so much objectively terrible code out there. Not only does it exist, but it actually generates revenue. I recall being simultaneously amazed and disgusted.

Writing the first (small) program (I think drawing a line in qbasic) that, on the very first try, went through the compiler without any warning or error and did what it was supposed to do.

The day I stopped worrying about not knowing everything, and that if you break a seemingly impossible task down into small enough parts it soon becomes clear on what is actually required.

Someone offering to buy my program. I was 13 or 14 years old and wrote a program in ZXSpectrum BASIC to mange a schedule of upcoming movies for a local broadcasting outfit.

Deploying changes that I’ve worked on and seeing things working in production. Terrifying at first, eventually it becomes a non-event - which boosts confidence.

I always wanted to make a game. So I made one. And it worked. It's horrible code. Its bad game design, but I made this, start to finish.

Getting a pull request accepted in an open source project. (Thanks Cyanogenmod folks! Wouldn't be where I am today without you guys!)

Not knowing how to do it and reading and failing until I figured it out. Repeat for 15 years to become a skilled crafts person.

Just by reading and reviewing other peoples code and seeing it was pretty similar to my own, or how I would have done it.

Leaving my first job /s

and

Demo a wireframe in a gui builder to a visiting suit without him realising that it wasn't a fully-developed application.

There’s no “right way” when you’re a learner.

You’ll gain confidence when you realize you can just hack away until it works and that is OK.

I think working on a lot of small changes across different areas of a project and starting to feel momentum.

When you find out let me know. Almost 10 years in and I don't know what I'm doing most the time.

My first job at a software company was in the shipping room (this was when software was still distributed on physical media) when I was 16 years old. As I walked around the office I realized I was at least as skilled as most of the programmers who worked there, who were about 10 years my senior. Shortly thereafter the company gave me a desk and hired me as a programmer.

since confidence is orthogonal to capability: positive encouragement and uplifting comments from my seniors did the most for my confidence.

if the capability is the question, well i don't have any answers. 10 years in and the imposter syndrome is still strong.

Selling your code is a great confidence booster. That's what worked for me.

Being able to help my friends understand the basics of the pointer arithmetic in C.

A petty one: seeing people interview and bomb on simple questions.

Building a real product that people were willing to pay money for.

About nine years ago, Lee Hutchinson (Ars Technica) wrote an article[0] that has since become Canon, and is appropriated by everyone and their uncle.

In it, he describes "The Dunning-Kruger Peak," followed almost immediately by "The Jon Snow Trough." After these extremes, our confidence and self-appraisal starts to linearize.

I cannot say enough about being on teams with experienced engineers, and writing stuff that actually ships (as opposed to disappearing into an "Out" box, and we never see what happens to it).

WFM. YMMV.

[0] https://arstechnica.com/gadgets/2014/10/smartphone-camera-vs...

Finishing projects.

Ask HN: What boosted your confidence as a new programmer?

Naivety!

Ignorance!

Hubris!

And all of that has given me NIHilism!

Learn your dev tools inside and out.

Learning the syntax of my language really well.

seeing seniors making mistakes, warning them, being ignored and then being proven right contributed the most

A good mentor.

git reflog

git grep