61–70 of 245 posts
It kind of puts into perspective how software works.
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 p…
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 bel…
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.
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.
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 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.
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...
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.
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)