by optbuild on 7/5/23, 7:17 AM with 229 comments
Similar things happen with novice programmers when they start out.
Then they read a beautiful codebase which they can fully understand and replicate, or build a project from scratch, or read a book or take a class on a subject. And their confidence is tremendously boosted thereafter.
What was it for you? How did you gain this confidence to take the first step from being a tinkerer to being a skilled craftman?
by mindfulmark on 7/5/23, 6:35 PM
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.
by specproc on 7/5/23, 7:02 PM
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.
by JohnFen on 7/5/23, 8:56 PM
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)
by PaulRobinson on 7/5/23, 6:58 PM
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.
by wavemode on 7/5/23, 9:23 PM
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.
by porridgeraisin on 7/6/23, 5:39 AM
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.
by abc_lisper on 7/5/23, 6:40 PM
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.
by lll-o-lll on 7/5/23, 10:55 PM
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.
by samhuk on 7/5/23, 10:39 PM
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.
by bmitc on 7/6/23, 3:02 AM
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.
by gamacodre on 7/5/23, 11:34 PM
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.
by syntheweave on 7/5/23, 9:03 PM
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.
by yodsanklai on 7/5/23, 7:24 PM
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.
by Izkata on 7/5/23, 7:07 PM
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.
by poppingtonic on 7/5/23, 9:50 PM
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.
by codeptualize on 7/5/23, 8:50 PM
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.
by stopthe on 7/5/23, 10:33 PM
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.
by ftxbro on 7/5/23, 10:51 PM
by jconley on 7/5/23, 9:25 PM
by magarnicle on 7/6/23, 12:24 AM
I was just learning the relevant languages and jobs, so their response gave me confidence to keep trying things and learning.
by dieselgate on 7/5/23, 6:45 PM
by hutzlibu on 7/6/23, 7:38 AM
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)
by emodendroket on 7/5/23, 6:50 PM
by lukeck on 7/6/23, 5:29 AM
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.
by austin-cheney on 7/5/23, 9:23 AM
by mattbgates on 7/5/23, 10:26 AM
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.
by serial_dev on 7/5/23, 9:03 PM
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.
by chx on 7/6/23, 4:46 AM
I was smiling reading git here -- the above happened before CVS was invented. I am old.
by ravenstine on 7/5/23, 6:40 PM
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.
by delta_p_delta_x on 7/5/23, 9:08 PM
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.
by LarryMade2 on 7/6/23, 3:12 AM
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.
by mgerdts on 7/6/23, 3:12 AM
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.
by cm2187 on 7/6/23, 8:05 AM
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.
by hospitalJail on 7/5/23, 6:33 PM
by zwieback on 7/5/23, 6:57 PM
by ezekg on 7/9/23, 6:46 PM
by TheCapn on 7/5/23, 6:55 PM
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.
by prepend on 7/6/23, 12:38 AM
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.
by tetha on 7/5/23, 10:21 PM
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.
by hyperific on 7/6/23, 12:34 AM
by thealienthing on 7/6/23, 3:13 AM
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
by em-bee on 7/5/23, 10:17 PM
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.
by KnobbleMcKnees on 7/6/23, 9:08 AM
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.
by boffinAudio on 7/6/23, 7:29 AM
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.
by elteto on 7/6/23, 12:18 AM
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.
by astee on 7/6/23, 3:03 AM
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.
by rsaxvc on 7/6/23, 7:52 AM
About four years after he reviewed a series of changes me and two coworkers put together to rework this handling.
by nailer on 7/5/23, 7:25 PM
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.
by ezedv on 7/7/23, 1:35 PM
by hugocbp on 7/6/23, 1:27 AM
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.
by edulix on 7/6/23, 3:24 AM
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.
by franciscop on 7/6/23, 2:41 AM
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).
by yayitswei on 7/6/23, 4:46 AM
by TheBigSalad on 7/6/23, 3:05 AM
by foobiekr on 7/5/23, 7:15 PM
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.
by aldousd666 on 7/5/23, 9:39 PM
by MilnerRoute on 7/5/23, 11:58 PM
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.
by closeparen on 7/5/23, 11:30 PM
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.
by tezzer on 7/5/23, 6:37 PM
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
by jcpst on 7/5/23, 11:50 PM
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.
by 100011_100001 on 7/5/23, 6:55 PM
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.
by jjaken on 7/5/23, 11:51 PM
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.
by easeout on 7/6/23, 6:22 AM
by Barrin92 on 7/6/23, 12:33 AM
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.
by constantcrying on 7/6/23, 7:30 PM
Also realizing that a lot of people write really not all that good software was another big point.
by munk-a on 7/5/23, 7:19 PM
by Zambyte on 7/5/23, 6:43 PM
by marshmellman on 7/6/23, 7:16 PM
It exposed me to _other_ people’s knowledge gaps, and made me realize how many things I actually knew and understood.
by saboot on 7/5/23, 6:47 PM
Seeing shapes collide, bounce, roll, and understand exactly what was happening in the code I wrote was a huge confidence booster.
by runjake on 7/5/23, 9:21 PM
Start on real projects as soon as humanly possible, even if they're junk to begin with.
by pragmatic on 7/6/23, 2:54 PM
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.
by hajmo97 on 7/6/23, 7:47 AM
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.
by ashton314 on 7/6/23, 5:11 AM
Also, learning Git was incredible to my confidence in modifying code.
by amai on 7/5/23, 7:17 PM
by sanderjd on 7/6/23, 12:44 AM
by jstanley on 7/5/23, 7:26 PM
by sodafountan on 7/6/23, 4:52 AM
by brailsafe on 7/5/23, 10:46 PM
by codr7 on 7/5/23, 10:31 PM
by otagekki on 7/7/23, 5:12 AM
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.
by saladoc on 7/8/23, 6:36 AM
by lelithium on 7/6/23, 8:35 AM
by tomcam on 7/10/23, 1:24 AM
by hu3 on 7/5/23, 7:07 PM
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.
by rythmshifter on 7/6/23, 1:00 AM
by acheong08 on 7/6/23, 12:57 PM
by autonomousErwin on 7/6/23, 8:34 AM
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)
by VirusNewbie on 7/5/23, 8:59 PM
It kind of puts into perspective how software works.
by OkayPhysicist on 7/5/23, 6:40 PM
by hot_gril on 7/5/23, 8:34 PM
by swader999 on 7/5/23, 7:31 PM
by prepend on 7/6/23, 1:54 AM
by killerstorm on 7/6/23, 12:20 AM
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.
by talonx on 7/6/23, 8:02 AM
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.
by contravariant on 7/6/23, 10:46 AM
For me that was when I crossed the line between merely tinkering and actually crafting something that could stand on its own.
by lucasyvas on 7/5/23, 8:00 PM
by tootie on 7/5/23, 8:58 PM
by robswc on 7/5/23, 11:23 PM
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.
by omgmajk on 7/5/23, 7:25 PM
by comprev on 7/5/23, 7:09 PM
It was also a great reminder that "good enough" is just that.
by 10g1k on 7/6/23, 1:26 AM
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.
by jlund-molfese on 7/5/23, 6:51 PM
by jasongi on 7/6/23, 12:54 AM
Eventually you get enough general knowledge to pick up almost anything and figure it out.
by pprotas on 7/5/23, 6:00 PM
by kuon on 7/5/23, 9:02 PM
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.
by mdrwsh on 7/6/23, 8:28 AM
by aviperl on 7/5/23, 11:20 PM
by NanoWar on 7/6/23, 11:15 AM
by writecandace on 7/6/23, 2:15 AM
by poulsbohemian on 7/6/23, 2:53 AM
by rubicks on 7/6/23, 3:38 AM
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.
by ori_prior on 7/6/23, 12:22 AM
by siquick on 7/5/23, 9:53 PM
by rdtsc on 7/5/23, 9:23 PM
by web3-is-a-scam on 7/5/23, 9:08 PM
by FreshStart on 7/6/23, 5:48 AM
by swapsCAPS on 7/6/23, 7:43 AM
by kentf on 7/5/23, 9:22 PM
by hkon on 7/5/23, 10:10 PM
by andyjohnson0 on 7/5/23, 7:22 PM
and
Demo a wireframe in a gui builder to a visiting suit without him realising that it wasn't a fully-developed application.
by andrewstuart on 7/5/23, 6:46 PM
You’ll gain confidence when you realize you can just hack away until it works and that is OK.
by jrumbut on 7/5/23, 6:47 PM
by OldManRyan on 7/5/23, 9:03 PM
by kmoser on 7/6/23, 4:17 AM
by LesZedCB on 7/5/23, 6:54 PM
if the capability is the question, well i don't have any answers. 10 years in and the imposter syndrome is still strong.
by santa_boy on 7/6/23, 6:02 PM
by 3yanlis1bos on 7/6/23, 4:50 AM
by agumonkey on 7/5/23, 9:25 PM
by aaronbrethorst on 7/5/23, 9:23 PM
by ChrisMarshallNY on 7/5/23, 9:06 PM
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...
by optymizer on 7/6/23, 2:08 AM
by darkclouds on 7/5/23, 7:17 PM
Naivety!
Ignorance!
Hubris!
And all of that has given me NIHilism!
by genjii931 on 7/8/23, 5:34 AM
by tboyd47 on 7/5/23, 6:54 PM
by nathias on 7/6/23, 8:27 AM
by User23 on 7/5/23, 7:24 PM
by yewenjie on 7/5/23, 11:15 PM
by LarsDu88 on 7/5/23, 8:35 PM