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.

I’ve noticed this as well - they don’t view software building as a form of engineering that can be learned from basic principles of computer science, but instead as magic.

So the go to for every solution is to find a third party library from a “real” witch or wizard, and follow its basic tutorial. Maybe try to customize it a bit at most.

If something breaks, just start randomly moving things around or copying and pasting more code from forums until it works.

I can’t live like that. I need to know why something’s not working, AND why it IS working. I like stepping through my code with a debugger just to make sure things look right, even when they’re working.

I think the craziest part, though, is just how much people with this “software is magic” mindset can actually get just by brute force cobbling things together.

Oh, that's definitely true.

To me the issue is they assuming everyone around them is like this. I'm totally fine with lack of experience or knowledge, but a co-worker constantly underestimating their peers is not alright.

The senior developer above me is like this for me, and it’s rough because it shakes my self esteem AND often leads to me having to support and extend a fragile and changing 3rd party library to solve a rather specific problem that would be better solved with custom code.

Where it really stings is when I do something of my own initiative (like, for example, create a transparent API over memoizing and caching some expensive calculation, or refactor some of our common client customizations into their own set of classes so it’s easier to extend) and he ignores it or scoffs at it.

Only to then find a third party library that implements something similarly. THEN it’s presented to me as a “brilliant idea” that we can take advantage of.

At that point, when I say “we” already do this, he usually rephrases what his brilliant 3rd party library does, as though he can’t fathom that I would be capable of doing something like that myself, and clearly I’m just not understanding what he’s telling me.

I think it’s a defensive mechanism for his ego against one of his peers or employees being more capable than he is.

But it’s also not like he can’t learn this stuff himself, he just doesn’t ever put in the time or effort.

With many exceptions (the left-pad debacle comes to mind), it’s generally much better to use a third party library instead of supporting your own implementation.

I know this is the mantra, but my experience has been highly mixed and only generalizable to how low in the stack it sits.

For, say, security implementations for authorization and access controls, or even low level HTTP request routing? Absolutely. The goal there is to adhere to something standard and battle tested by experts, and the third party libraries tend to be fewer in number, and of higher quality, with longer term support and clearly defined upgrade paths.

But that’s the lower level stuff, where your special custom needs are superseded by the primary goal of just “doing the one right thing”, or “adhere to the commonly agreed upon standard”.

For all the other things that make an app unique - things like CSS frameworks, UI components (beyond basic, accessibility-minded building blocks), chart drawing, report generation and caching - my experience has taught me otherwise, the hard way.

Being stuck using a 3rd party library that doesn’t do what the client or business needs it to do, having to juggle our own internal patches and bug fixes with updates to the library itself, all only to have the library abandoned or deprecated in favor of the author’s next pet project, really sucks and often comes with a high opportunity cost and a high development cost.

I now consider third party implementations of higher level features (and especially anything front-end) to be something that needs to be evaluated as equally costly as an internal implementation by default, and not favored just because somebody else wrote it.

Maybe I’ve just been unlucky in my experience, though. I also suspect ecosystem makes a difference. The PHP and JS ecosystems are full of poor libraries with snake oil sales pitches. I suspect this is different with, say, Rust.

I think we mostly agree with each other. As I said, there’s many exceptions.

I’ve mostly worked with Python and JVM languages, which probably explains why I’m less passionate about the counter-argument than you are. Ecosystem definitely matters a lot. VanillaJS is the only good JS framework IMO.

I’ve never met a developer with that attitude, but I’ve met too many managers with it. You’ll be even less of a fan of working for those developers, I guarantee it.

That mediocre dev is a straight shooter with middle management written all over them…

I think it depends on the industry and in location. In my neck of the woods I'm seeing an uptrend towards more technical managers, or sometimes a mix of lead developer and manager, who can actually get things done.

It's a matter of preference but IMO/IME it works better when a manager is actually good at it.

A manager that is supposed to be technical but only wants/knows how to do the management part, and can't make more than the basic stuff won't really fly. I've seen a couple of those getting fired during probation period.

On the other hand, the "bad developer" that thinks packages are magical will eventually settle as an expert beginner in a low-expectation environment. Which is fine.

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.

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

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.

In python pdb ‘breakpoint()’ is great

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.

Had a similar experience during my Bachelors thesis. I was adding new functionality to an existing code inspection framework and was also supposed to add a graphical interface with GTK (this was 2014). At some point I identified a performance bottleneck within a GTK component. My advisor suggested fixing it and I just couldn't understand how I lowly student am supposed to tackle anything in this big behemoth. In the end, I didn't do it but it made me think and jump into various big open source projects in the following years. And you get used to navigating these suprisingly fast.

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

I think the real skill then is to learn to navigate big codebases in few days time than taking a few weeks and then feel dejected by the time spent and still unsure.

I often feel ambitious for such endeavors but navigating big codebases take time, any tips?

It helps if you can get your IDE's indexer configured, so that you find refererences to functions and variables reliably.

More importantly is to use an IDE with a good fast global search function and get comfortable with it. At least for me, 99% of navigating a large codebase is global search.

Or use an ide that doesn't need indexed configured and just works

Is there a way to get vscode to this level.

For C++, I use clangd (works fine for GCC projects). The only config it needs is the path to compile_commands.json, which can be automatically generated by CMake and some other build systems. For TypeScript no config is needed. For Java there is the redhad Java plugin in VS which provides good indexing.

Not using VSCode currently but I think pretty much yes.

You can goto or peek definition in VSCode. And the find tool has the option to find all occurrences throughout your project.

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.

CGO_ENABLED=0 for new projects though :)

Just calling out that if it weren’t for open source this would be much harder

Imagine any other profession needing to inspect, rebuild, and fix the tools that they are given to do their job.

that's actually, um...common? i just had to repair an electric jackhammer last week. i worked in a machine shop for a large well drilling company not long ago, and not only did we create/repair tools for the company, but obviously had to keep our mills and lathes and cranes, etc. in good working condition.

It's not common in the same sense. First of all, tools are very different from software products. And there is never the same level of analogy that one has to do in software.

Imagine buying a hammer, that hammer not working, the hammer's design being so complicated that it's impossible to understand or mend, and then having to design and build your own hammer, and then putting up with that situation over and over again and accepting that as the status quo. That would be the correct analogy.

I'll agree wholeheartedly that the analogy needs some work. Tools are different - we have our literal physical tools that we don't generally dive into (keyboards, mice), we have tools that are maybe more battle tested and rarely examined (cat, grep, find).

We have do have tools like the hammer - there is one design, everyone more or less agrees on it. There is still high quality and low quality, but it has one job. We have tools like a bulldozer - complex, numerous parts, requires constant maintenance, closed source.

As the parent said - it is not uncommon to have to maintain old equipment, as well as design new tools as new requirements pop up.

Sure, our rust is a little bit different - time wears on software in a different way. Use wears on software differently. (Changing product requirements leading to a new tool is probably common.)

The maintenance may be trickier - but I'm sure changing components on a tool when a certain component is no longer available is not easy, thats where shim layer comes from!

Have you met farmers? They will readily tear apart their equipment to fix an issue or modify the tool to make them more ergonomic. This trend of massive multi-million dollar John Deere combine harvesters with DRM widgets that you need to take to a specialized tech to get fixed, is a relatively modern one, and one detested by virtually every farmer.

This was and is quite common in any blue-collar field where works don't always have the money or time for a brand new jawn every time something goes wrong.

I love estate/yard/garage/barn sales and going through the tools and reading the tales they tell from their wear patterns, field repairs, revisions, and hacks from their owner.

Case in point, here's a tool which has gotten multiple leases on life through modifications. https://youtube.com/watch?v=oTA513ttrbQ

I worked on a farm. I think the things you're bringing up are still subtlely different. Modifying something you can see and touch for some unintended purpose versus modifying some piece of software because it doesn't work are miles apart from each other.

For example, I have a graphics project where screen tearing suddenly started appearing although my code didn't change, and the tearing wasn't there before. Is the issue in Skia, OpenGL, the graphics driver, the Intel or NVidia GPU, or the OS? Or is it some latent issue in my code that started showing up because of a change in these dependencies? Or is it some other complex interaction between multiple dependencies? I couldn't possibly know, and I actually don't think there is anybody that actually knows. And there is zero chance I could ever figure it out. I mean, it at least appears it was a driver issue as after some updates and a reboot it just went away, but there is zero insight into why or what actually made it go away.

If I modify a plow because some part as originally designed was flaky and constantly broke, you usually know to a pretty good degree why your fix works.

In software, the abstractions are such that it is practically impossible atbtimes to understand.

That to me sounds like a difference of degree or heap problem, rather than a categorically different condition.

Sure, welding back on a hardpoint that broke off a plow is concrete and obvious (maybe that's analogous to fixing a broken dependency that got renamed), but there are other fixes that definitely fall under "I don't know why it works but it works". I've had electrical gremlins and fixed them by grounding something that looked like it ought to be grounded, and was grounded when I tested for continuity, but nonetheless was acting floaty. It was probably a loose connection elsewhere in the system, but I didn't know that for sure, nor do I even know that it was the problem in the first place.

Software definitely reaches insane depths of complexity, but again, if you can dig down and understand the abstraction well enough to attempt a fix, and the problem goes away, isn't that good enough? The real difference is mechanical systems typically only have a few layers of abstraction, while software has dozens to thousands of layers of abstraction.

I feel like this is quite common but it depends on the optics of situation.

A mine site usually fixes its own tools used to do their job, they usually fixed things they've purchased to use that are broken or become broken, is that not the same?

I highly doubt that a mining operation finds it acceptable that tools that they have purchased show up broken, undocumented, and unsupported.

Your job as a developer is to write code and piece code together to make your life easier. That includes taking the work that others have done and make it work to suit your code base.

On a mine site, the job is to mine and process minerals. That includes engineering a mine using products that eventually fail over time and need fixing. As part of that process an automotive electrician may need to fix the electronics on a vehicle that have become faulty or damaged.

Mechanics and engineers need to inspect, rebuild, and fix the tools they are given to do their job. The difference is that yours may not work up front, whereas these tools need maintenance over time.

When I was doing enterprise work with closed-source libraries, any defect required them fixing it. We've found some issues with AWS and they fixed it too.

The difference between most professions and programming is that we have open source. The equivalent of that in the real world is getting blueprints to build our tools and then building them ourselves, with no guarantees.

You'd be surprised how common it is.

I've worked in many industries, and none of them put up with the poor state of tools and treat it as a given like the software industry does.

Hmm again I think mining are pretty good at making do with the poor tools they have

Very different situation

I've also found that the software industry obsesses over tools more than any other industry

"I was an ordinary person who studied hard. There are no miracle people. It happens they get interested in this thing and they learn all this stuff, but they’re just people." - Richard Feynmann

Not all external dependencies are noncompiled. Also, library code is often different from your regular codebase especially in a language like C.

This. My favorite language for this is Clojure. There's usually not much library code to sift through because it's so terse.

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.

"If it's the latter, what you're really struggling with is not the library, but the domain it's trying to represent."

But this doesn't change anything of the programmers problem. If I stumble on a bug in a physics libary I am using for a game, I cannot just jump right into there and go fixing things. I mean I can start doing it, but at the cost of not getting anything else done for quite some time.

There are lots of hard domains in programming. Cryptography is hard. Networking is hard. Fast rendering is hard. Efficient DBs are hard. OS are hard. Drivers are hard.

You can maybe fix a trivial error in such libaries, but everything else is usually a (big) project on its own.

Absolutely correct, but I think it’s still valuable to be able to recognize if you’re struggling against the code or the domain.

Additionally, once you recognize that you can also recognize if you’re dealing with incidental complexity (e.g. poorly thought out/designed code) and inherent complexity (e.g. physics calculations). The former can be fixed, the latter cannot. Knowing the difference saves much pain.

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.

I've recently had two engineers assigned to help me. I feel the same as you - I know a lot of my work is trash (for good reason, but still - not code to be proud of), and it is also true that I forgot just how many varied skills I had to acquire to be able to do the work I do.

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

Well said! Thank you for reminding me of this.

As someone who is on the same path as you, many years/hours behind, thanks for sharing.

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 believe in being as bluntly honest with yourself as possible. This includes acknowledging the good things as much as acknowledging the bad. So I think it's perfectly fine -- even good -- to recognize areas where you are an expert (just don't think that expertise in one thing makes you an expert in all things).

Humility is a wonderful thing, though, and you can maintain it regardless of your skill level by recognizing the truth that no matter how good you are at anything, there will always be someone better than you.

I personally get nervous when I'm not doing something I'm a novice at. It means that I'm not growing.

> as I saw more and more code written by programmers

That's what worked for me. By the time I was hired for real, full time coding work I had already done lots of C-64 Basic and assembly, x86 assembly, C in DOS and Win32 and had been reading DDJ for years. When I discovered the hopelessly abysmal code that supposed veterans had built their careers on I knew I was worthy.

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.

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.

Reading Designing Data-Intensive Applications was great in this same sense. Anything concurrency and distributed was always a mythical black box to me. It turns out, there are no real, all-encompassing solutions to these issues. It’s all trade offs, and each solution has some aspects it can’t help with. Vector clocks (allow ordering but only logically) and CAP (availability vs consistency under network partition) theorem are terms that come to mind.

nand2tetris often comes up on HN. I like to link to a similar, fully in-browser game which I think achieves the same: https://www.nandgame.com/ (no affiliation, I just really liked it)

Can I accompany this with the original course / book?

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.

This was my way as well. Start early, respect the steepness of the learning curve, and just keep going.

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

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.

I usually don't respond to comments, but there's a lot of things that I can identify with in your comment and I'm far from experienced as a developer.

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

Learning on my own and participating in online communities, receiving feedback and coming up with project ideas led me thinking that this field is creative and people treat it as a craft. The hiring process has you either do leetcode, show off your projects and talk about them or both.

Given the above, it's easy to understand why someone would expect to see the same in the job. But instead what you get is completely the opposite. My first job felt like I joined a restaurant that actually is a fast food joint, and the metric of performance that makes people happy is how many burgers I can churn during a sprint. Documentation? Can happen later. Testing? Slows us down, test by hand.

And on top of that I had teammates who refused to use the phrase "I need help" and "I was wrong", almost as if it's a sign of weakness. I don't know if it was their upbringing, culture or just because they had to demonstrate perfection to show how worthy they are of their position, but it sucked and I ended up spending more time tiptoeing around their ego than being an actual junior engineer, so I had to quit and recalibrate my career goals.

I'm sorry you had to go through that. Sadly, IT is full of 'colorful' characters like these. I've been on multiple projects that could have been so much more fun and lighthearted, were it not for 1 person. Due to their influence (whatever it is) the atmosphere completely changes and eventually people lose interest in the product, burn out, quit or are laid off because of it. No good can exist without the bad I guess.

Writing extremely good quality software is hard and expensive. In the vast majority of cases all you need is okay software developed by people who just want to get the job done. Understanding how software creates value and what kind of software at any moment is valuable; and which parts of your job is tied to that process makes this much clearer.

If anyone reading this just want to write bash scripts that don't violate fundamental principals, there are jobs out there, but they're typically low paying and academic

> Understanding how software creates value and what kind of software at any moment is valuable; and which parts of your job is tied to that process makes this much clearer.

This is a good point and something that is indeed requires a lot of care and thought and experience to tackle properly, but I think it strongly hinges on the assumption that software just does a thing, so to speak. Whereas I personally view software as something that does a thing but at the same time as something that is also a communication system and encoding of domain knowledge. So if the communication and encoding parts of the software are missing, and all you've got is it doing something, then in my view, the software is leaving value on the table over the long term. Poorly tested, understood, documented, and specified software will have waste products over time, siphoning value away. But it does so much more quietly, but in no less magnitude, than when software is not doing what it is supposed to be doing.

You are correct, but current geopolitical conditions and economic policy have created financial situations that basically enforce short sightedness on the side of corporations. If your employer is publicly traded or has institutional investors; they need to report quarterly earnings. Investors won't care about code health or the longevity of a product, they only care about sales/revenue.

It's a fundamental systemic issue that's why we see so many tech companies produce terrible products. But we (the programmers) have no ability to fix the shortsightedness of the American financial system.

Do you have any examples from your experience about making that distinction? Sometimes I struggle with the boundary between good maintainable code and meeting deadlines.

Writing bad quality software is often even more expensive.

It sounds like you have a commitment to excellence not shared by your peers. As sibling comment points out, good enough is good enough for most businesses. I like Paul Graham's quote from his book. "The goal of big companies is not to write quality software, but to suck less than their competitors."

My confidence as a software engineer comes from the gratitude of my users. Giving them something that makes them light up and say "I had no idea I needed this." I've worked in many organizations where layers of bureaucracy smother that joy. Having a direct line to my users is incredibly motivating.

Many comments touch on the "do it for the users" mentality and I'll add my own take. There's a book called "The Science of Drawing" by Harold Speed. It's a pretty rigorous dissection of drawing written in 1913. However, despite its clinical writing style, the author notes that the highest praise an artist can receive is "Oh." Not "It's beautiful," or "I really like it," but a raw and spontaneous emotional reaction. Dissecting art is only as useful as a means to produce more of it, the emotional communication is the actual core of the medium. Software is very similar in this way.

Thanks very much for the encouraging reply. This is rather helpful and deep advice.

> It sounds like you have a commitment to excellence not shared by your peers.

Just to be clear, my sentiment is one built up over time and experience and not directed at any one company or colleague. There are kernels of this everywhere though. I'm also a part of it all. I've definitely made things more complex than they've needed to be, but I do attempt to learn from that and revisit approaches.

> Giving them something that makes them light up and say "I had no idea I needed this." ... Having a direct line to my users is incredibly motivating.

This is a really good point, and thank you for saying that. Your advice here is very helpful. I have had the most fulfillment when having a direct user being able to use software I've worked on to do their job better.

> There's a book called "The Science of Drawing" by Harold Speed.

Thanks for this book recommendation! I'm going to check it out.

> the author notes that the highest praise an artist can receive is "Oh." Not "It's beautiful," or "I really like it," but a raw and spontaneous emotional reaction.

Even though it was not intended this way, one of the greatest complements I ever received on software that I personally and solely wrote was someone opening up my code and saying "where's the code?!" in a completely bamboozled way and also a way in which they were legitimately worried if it actually did anything. Haha. They were used to hodge-podge collections of code stuff into a single file doing absolutely everything under the sun. So when they opened up my code, they were legitimately bewildered that everything was modularized, componentized, etc., and for a half minute they were suspicious that there was even anything implemented. It was confusing to them that things were labeled simply as "do this specific thing" (as an abstract example), and it actually just did that specific thing rather than a block of spaghetti code doing something but god knows what.

Judging by my performance reviews, I’ve gotten way worse at my job over time. They LOVED me as a junior, they despise me as a senior/lead. Only difference is that as a junior, when the boss came by and said “let’s do it this way,” I said wow, cool, teach me! Now I say “No user has asked for this, your design is overcomplicated, and we need to factor in an extra three weeks for the overdue tech debt fixes I’ve been warning you about.” And the reaction towards me actually using my knowledge and job skills is so extremely negative that there goes my confidence. This industry is kinda screwed up.

There are a lot of zombie companies that only exist due to bailouts and zero interest rates. Sounds like you’re at one of them. Inflation and interest rates aren’t going down any time soon.

It’s all cyclical. The decadence today will eventually give way to another recession, and we’ll build something better from the ashes.

I’m also growing increasingly disgusted by the state of the industry. Things weren’t so messed up 10 years ago, but salaries were also not so ludicrous at the time. I suppose I should be careful what I wish for, but I’d appreciate some disruption right about now.

I couldn’t agree more.

I could live with apathy towards documentation, but it goes beyond apathy. There is often outright hostility to anyone who “wastes time” writing documentation or doing design work. Agile grifters have absolutely ruined this profession.

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.

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.

So your distinction is that hackers gravitate towards extensions of turing completeness (i.e. code representations) as opposed to mechanical systems like basic engines and or machines?

This seems mostly true in my personal life. As a hacker, it explains my 5 year obsession with minecraft and gmod in my teens. I got deep into gmod e2 and then actionscript3 (RIP). It also explains why some mechanically gifted people I know don't "get" the flexibility of code, despite their intuition for systems. I think it takes a certain conviction to modify and extend abstract systems. Problem diagnosis is not obvious and can be very frustrating. But the dopamine hit of seeing things work together is enough to keep me going.

Overall, my hacker foundation is built on a never-ending loop of frustration and desire. Frustrated things aren't working with a desire to make things happen. I didn't program professionally until recently, but I instantly understood the mentality. I'm grateful for the wisdom my career has given me to pursue it.

> "So your distinction is that hackers gravitate towards extensions of turing completeness (i.e. code representations) as opposed to mechanical systems like basic engines and or machines?"

Oh I didn't mean that at all, they could like engines too or even more, just they aren't turing complete (unless you mean like babbage machines or that crab gate machine which I assume most children wouldn't create or have access to). I meant that usually these proto-hackers as children at some point will have accidentally found a turing-complete thing and played with it when they were children before they learned programming officially, even if they like other things more. Then the moment "the first step from being a tinkerer to being a skilled craftman" would come when they learn that programming is a thing and they find it's actually so much easier than the convoluted logic systems they were making themselves.

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.

>The attitude of my bosses.

This is absolutely IT! Everything else is secondary. Nothing boosts a noob's confidence as the fact that his boss trusts him to deliver on the project and gives him the responsibility and positive support needed to do so.

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.

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.

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.

Where did you learn to see it like that?

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

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.

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.

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.

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

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.

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.

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.

yes great stuff

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

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.

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.

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.

Standard library != syntax

Sort of? It depends on the language but a lot of times syntax is just a fancy sugared way to invoke weird functions - i.e. `if (a === b)` might just be `if (a.equals(b))`. I work building tools to make other people more productive so a lot of the time I'll build out functionality I'm implementing using sugared syntax to make it cleaner. In some languages this isn't possible but most modern languages allow metaprogramming of some form or another.

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

A good mentor.

git reflog