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.

This is indeed a superpower.

I don't really remember when I felt that external dependencies were magic, but thinking about this, it explains a lot of the behavior I see on some developers who are very negative about the more challenging parts of the job.

Some of them don't really believe the research stuff we do at work are even possible. They're constantly surprised when other devs finish those tasks. Some don't believe that other devs can code in C++ or Rust, or write parsers, database modules, implement IQueryable in C#, or develop novel algorithms for novel applications.

To them, if a package exists it must just work, and that package comes from another breed of developer that can't coexist with them. I see a similar thinking with AI: now with ChatGPT and GPT-4, there's a hubbub about there being "no reason for our AI team to exist anymore".

I'm not a big fan of working with those developers.

> I'm not a big fan of working with those developers

I agree. And it ties into something I often see that puts me on edge: programmers not taking responsibility for the code they put into their projects.

What I mean is that when you incorporate any code, from any source (library, framework, copypaste, etc), then you are responsible for that code and its proper behavior as much as for the code you actually wrote. So you're well-advised to understand it.

That's one of the reasons why I won't include code that I don't have the source code to. I need to understand it and be able to fix it.

Good point.

The "out of sight, out of mind" approach doesn't really work for code you're actually responsible for.

I've worked with some of those folks too. It seems to me like they haven't really learned programming the way I understand it; instead, they've learned various incantations that can be strung together, and are just at a loss when they don't work as expected/documented.

Funny thing was I never even thought to do this until I was working on a very strange bug, and a senior engineer at my company suggested I look at the source code for one of our dependencies. Sometimes really obvious and basic advice can be a big step for people.

Yeah I think it's helpful to recognize that this isn't always obvious to people, even folks who seem like they'd instinctively do so–I had a similar experience a year or two into being a professional programmer, despite being someone whose first experience with dependencies years beforehand was downloading Perl files and directly editing them.

Adding to this, the decompiler built in to many ides really up'd my game understanding underlying libs. How they work, what methods to call, etc. Very helpful! As much as people trash java this is a really nice feature. I'm sure other languages have decompilers as well, but I've never seen anything close for c# for example.

>I'm sure other languages have decompilers as well, but I've never seen anything close for c# for example.

Dotpeek is integrated into Rider and is a world class decompiler. It also integrates into Visual Studio either standalone, or with ReSharper.

You can also integrate external source symbol servers into your IDE of choice as well that will let you debug into libraries seamlessly.

In the case of Java at least, what helps is that the IDE can decompile the code or, which is often even more helpful, download the source code and allow you to step through it while debugging, at least if a source JAR was published (which is pretty often the case).

In the case of non-compiled languages, of course you don't even need this step since all your libs exist in source form already, so it was pretty simple for me to step through Ruby library code with a simple debugger and no fancy IDE.

I have a habit of sometimes debugging even horribly abstract framework (e.g. Spring) code when I don't understand what it's doing. That's maybe not the most efficient method, but it does usually make me understand why thing X is not working the way I expected it to work.

>I've never seen anything close for c# for example

If you highlight a method you call from external code and hit CTRL + F12, Visual Studio will automatically decompile it for you.

My favourite language for this is Go. The standard library is totally exposed and easy to jump into, right there for you to learn from and to make sense not only of the library but how to actually write Go in the first place.

Relatedly, understand the frameworks that you build upon.

For React devs, this means learning how React actually works under the hood.

Whenever I have this situation, it's always with a library too big for my smooth little brain to comprehend.

The trick is to dig deeper into those big library's dependencies as well. It's turtles all the way down.

The other thing I find is that big libraries are either mostly dependency bloat (as implied above) or dealing with a hard domain problem. If it's the latter, what you're really struggling with is not the library, but the domain it's trying to represent.

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)

I think this is big. I still try to be humble and consider myself to be nothing higher than a novice. When I do see things that I can quickly understand and even improve on, it's a huge boost to my morale.

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 someone who is on the same path as you, many years/hours behind, thanks for sharing.

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.

The brutal truth of it is that while there is beauty in the craft, in the end shipping is what matters. Getting things in front of the people that need them.

There's a nice concept in theater that says, effectively, "if you blow a line, don't broadcast it to the audience." The subtext of that is, simply, the audience doesn't know any better and what they don't know, won't hurt them.

By and large, this applies to many fields, and certainly to software development. The users, in the large, do not care over a huge amount of stuff that we, as practitioners, care about.

We're in a results business. The users care that they get the report they want or can update the data they're supposed to. How that's done, in the back end, is filed under "blah blah blah".

The reason this is important is not as an excuse to do crummy work, or to not be passionate about the minutiae that consumes us, but to be cognizant that as long as the end result is functional and capable for the user, it's OK for the processes that get to that point to be a bit messy. Don't beat yourself up over a lot of the things we beat ourselves up, or criticize others over.

Ship. Get your code in front of users, interact with them to make their experience better. We are in a service industry. Strive to be better, but you only get better by shipping, and moving on.

The confidence is that, for the most part, "it's just software" and you can fix it. You can change it later. You can correct mistakes.

Another saying is that you're not a professional until you've lost production data. Thankfully in our work, loss of production data rarely kills people, in contrast to the path of becoming, say, a doctor. If you are in an industry where people can be hurt, then that's going to be more rigid, for obvious reasons.

I have lost data, I have been SCREAMED at by clients, I have stood under the withering "What has just happened here" glare from management. It happens. Ah, the warm camaraderie of being thrown into a data entry pool to help rekey some of the 6 months of data you destroyed. A cold truth in our business is that it has to happen, as we only learn through practice, and through practice, sometimes we miss.

But to do that, we have to ship. We have to get the work out there, "I don't test often, but when I do, it's in production". Sometimes you just got to open the firewall up, let the traffic in, and see what happens.

A cynical view is the that the more we ship, the more we learn what we can get away with. There's a truth to that as well. We're all victims of not listening to "you're not going to need it". For all sorts of values of "it". But that doesn't mean we can't keep those concepts close, practice them as best as we can (because, truth is, sometimes you do need it!).

Through the work, and shipping, you learn the balance, and get more comfortable with it.

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.

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.

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.

Really nice sentiment, make sure you pay it forward; we need more dreamers in CS

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.

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.

What sort of Turing complete systems are you thinking of?

It could be a game like terraria or minecraft or factorio, or a game map editor, or a middle school hand calculator, or spreadsheets, or an automatic hotkey or macro app, or anything that is at all flexible or extensible. Of course several of these wrap real programming languages but it's not obvious at first especially if you never did programming. There are so many ways, and it's likely that embryonic hackers will come across something like this and use it to make silly program-like experiments and tinkering before they learn how to program. Or at least that was true earlier. Maybe replacement of computers with phones has changed it, I don't know.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Honestly, youre doing great. At the very early point in your career that you are at, it is normal and expected that you dont know much. The important thing is that you just keep learning.

There will always be people that are smarter than you. Perhaps even better at your job than you are (currently) in every way. Dont let it get to you; there's nothing wrong with not being the very best. There's also the old saying that "comparison is the theif of joy" (idk who said it, but it has truth). The hardest part is accepting it's ok not to know something; you can always learn it if it interests you.

> Someone asked me 'hey, you have a CS degree, tell me how ChatGPT works.' I couldn't answer that.

Did you mention to them that they're a clown?

Honestly, what you're describing would be common to almost any software engineer I know at least. The entire world of computer science, programming and software is VAST. You're only going to know about a tiny bit of it. A physicist doesn't know all of physics in depth, a doctor only has a surface level understanding of most things, and deeper knowledge of a few. Our field is the same. You're going to get to know your little niche, and bits and pieces of others.

As for tooling, if Windows and Visual Studio work then great. Vim is just a tool.

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.

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.

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.

I have a similar story except the confidence came when I landed my first on-site job. Once I got in the team, the same realization came to me - I am not any worse than these guys here.

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.

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.

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.

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.

I am self taught. I was involuntarily reassigned from a design to a developer position and just had to learn to program.

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.

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

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.

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

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.

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.

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.

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

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

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.

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.

As a cartoon dog once said; being bad at something is just the first step towards being pretty good at it

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.

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.

You can always tell a true senior developer by the overabundance of imposter syndrome they carry around with them. Green programmers can see their successes - experienced programmers can see their flaws... the best programmers I've ever met can intuit which parts of a green programmer's system probably have bugs by just listening to them talk about it and focus in on the parts they don't go into detail about.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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!

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

Leaving my first job /s

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

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

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

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.

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.

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

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

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.

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.

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

Naivety!

Ignorance!

Hubris!

And all of that has given me NIHilism!

Learning the syntax of my language really well.

Eh, I've worked in PHP for more than a decade professionally and I still need to double check the argument order for array_walk. The syntax of how we express ideas abstractly is probably a better thing to focus on than any specific details tied to the language.

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.

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

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.

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.