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 a…
Ask HN: What boosted your confidence as a new programmer?
181–190 of 245 posts
Re: Ask HN: What boosted your confidence as a new programmer?
#182Earlier quoted context omitted.
I highly doubt that a mining operation finds it acceptable that tools that they have purchased show up broken, undocumented, and unsupported.
You'd be surprised how common it is.
Re: Ask HN: What boosted your confidence as a new programmer?
#183Earlier quoted context omitted.
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 aga…
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!
Re: Ask HN: What boosted your confidence as a new programmer?
#184Realizing 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 p…
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.
Re: Ask HN: What boosted your confidence as a new programmer?
#185Earlier quoted context omitted.
> 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.
Re: Ask HN: What boosted your confidence as a new programmer?
#186Seriously, 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.
Re: Ask HN: What boosted your confidence as a new programmer?
#187Earlier quoted context omitted.
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.
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.
Re: Ask HN: What boosted your confidence as a new programmer?
#188By 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)
Re: Ask HN: What boosted your confidence as a new programmer?
#189Re: Ask HN: What boosted your confidence as a new programmer?
#190At 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.