51–60 of 245 posts
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.
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 e…
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.
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…
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.
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…
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.
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.
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)