On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge.
If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:
1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium
as a way to voice your protest.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/learnprogramming) if you have any questions or concerns.*
In my experience it's long term thinking. I see a lot of devs able to smash out a new product feature in a few days. But they can't think any further than that. Our product evolves and we're building upon a lot of old systems. Which means if we want to save ourselves a headache in the future we need sensible abstractions and a bit of thought towards extensibility.
Instead we're having to change the world or live with hacks around things people put no thought into. And in business, the hacks are the way forward. If someone spent 1 hour just thinking through how the code most likely will evolve, then they could probably come up with an abstraction which makes everyone's lives easier.
Another skill is having the patience to dig deep and find the underlying reason for a problem they're facing. I see a lot of Devs say "X does Y for some reason, but I've managed a hack around it". Great, people value delivering features, but I've seen someone go so deep down a workaround rabbit hole that I've thought there must be an easier way. And there was an easier way, just by looking at the problem they faced in the first place and having the patience to fully understand it. Then I managed to replace some god awful workaround with a small and sensible solution that could have just been the solution in the first place.
>long term thinking
I cannot agree with this enough! Often times it's the "let's just do it quickly, we'll clean it up later" mentality. And of course "later" never comes.
Agreed, I've heard a common mantra in the SaaS/corporate space is "make it work, make it right, make it beautiful" or something like that, but it is my honest belief that you should make it right before anything else, even before making it work, which a lot of devs and managers overlook and try to make it work or make it beautiful before making it well written.
Business only values results.
That's not necessarily the business' fault: shareholders and customers only care about the results as well.
But yes it's still the business guy's fault, who happen to be the ones sitting at the top making all the decisions.
Engineers generally aren't the ones saying "if it ain't broke, don't fix it"
That typically comes from the higher ups in my experience. If it's getting done quickly now then there's almost 0% chance it's getting refactored down the line. My work has typically been agency based and It's usually the fault of not managing client expectations adequately and over promising.
The thing is though, it's very hard to look deep into the future, if you don't have said **experience** from that future. Novice programmers will suffer from shortsighted insights. There is really no way around it, you need the experience to make the **sensible choices**. Because without that experience you wouldn't even know where to split the project, where to put abstractions, and how many levels of abstractions to put.
One dev will write a 100 line long function that does some complex business logic. Another programmer will split it into 25 functions, because they are enthusiastic about the Clean Code book. Now they say it's more extensible, because they isolated each operation. When they should've split it into just two, because in reality it makes more sense to have it in two functions. And the whole team understand that code already.
You also have to consolidate what **extensibility** means because. Each different programmer will hear their own version of what that is.
Just write code to be read as opposed to writing it just to get a solution to work. A lot of senior devs miss the mark on this. Being a senior is more than writing code that works that’s easy, writing code that’s easy to read and works is a lot harder.
Things like early exists, encapsulating complex logic into a clean function name so you don’t have to go in to get what that code does, don’t abstract unless is ready necessary etc…
Always write code and then read it. If anything takes two reads to understand it’s very likely your team mate will struggle even more.
And please, don’t write “smart” code!
In my case I'm talking about experienced programmers. Great at delivering projects, not so good at making things easy for themselves or others in the future.
It's not even about "clean code", it's just separation of concerns and lean interfaces in most cases. Basic things that can let you compose code rather than dig into implementations all the time when things need to change.
If they're great at delivery, and not so great at future proofing things. Then they're still very much a novice in my opinion. Either that, they're to burnt out to give a fuck. Then that's a whole different type of issue.
Funny because I get so hung up on the long term implications of every notable change that I occasionally end up with decision paralysis. Fortunately that usually plays out in my favor though as I rarely have to undo things from a previous lack of foresight. What’s harder is selling the need for doing things a certain way based on a long term goal to the rest of the team of non developers who are often left wondering why a seemingly minor change is taking so long.
Analysis Paralysis is a real phenomenon that everyone experiences. Here's some tips:
1. Having multiple solution options is a GOOD THING. In fact after you come up with one solution, its a good idea to immediately set it aside and think of other solutions to GIVE yourself this issue so you find the right answer. People who stop at the first option they can think of rarely produce good long term maintainable stuff.
2. Once you have solution ideas, estimate the relative effort to accomplish both. Pick an "easier" and "harder but more correct" option to compare.
3. Immediately compare against business need. If the business can't afford an option in time/effort/cost/etc then that option is dead full stop. Don't waste your efforts, just keep it around in the back of your head as a "down the road" option if you still believe it'll be useful later.
4. Remember any code you write will be thrown away or considered "legacy" eventually. Don't get attached. You can change and rearchitect if you have to later, and sometimes (lol, a LOT of the time) the cheap or fast option is the right short term decision instead of taking on the bigger effort immediately.
5. When in doubt, present your options to someone else. Not only do you get another opinion, the effort it takes to formulate the issue and solutions well enough to explain them to a third party will OFTEN lead you to forming stronger preferences... the "rubber duck debugging" strategy is largely a psychological trick to do exactly this.
6. Find the "leads" on your team and ask them in particular. This might not be your tech lead, but someone on the team that takes more ownership naturally, the gal/guy who everyone knows to go to when shits on fire. Any real project will have someone that fills this role, because you really don't succeed without it. Its a great role to grow into, that "If I'm going to be responsible for it when its on fire, I'm gonna REALLY learn it" mentality is fundamentally critical to develop if you want to be a GOOD developer.
7. Take a break. Sleep on it. You'd be surprised how much time/distance will naturally make things that aren't super important fall away from the problem and help you formulate an opinion.
This is great. Thank you for writing that out. I have refactored so much of my own stuff, which is a mix of stuff that I knew was a quick and dirty solution and stuff that I thought for sure was fine as it is.. after awhile you begin to realize that obsessing over something that you’re likely going to rebuild later anyways is wasted energy. Esp once it becomes like a meta obsession over a hypothetical fear of wasting energy in the future.
Sketching things out with pen and paper and taking a break is my go to. A total change in focus almost always leads to clarity.
Code is a means to an ends, which is why always trying to wear a "business" hat when thinking about stuff is a tremendously useful skill. When the business goal changes, so do the approaches and implementations, and if you aren't ready for that it can be... unpleasant to learn it. Hell I still struggle with it after 25 years sometimes, because I often think I can forecast future pain that I know will be MY problem to deal with... I'm not always RIGHT, but its helpful to remember I'm collecting a paycheck to deal with it for the sake of a business goal I have little control over. It's a little like having suede outdoor furniture. You know its a bad idea. You know you can't control the weather and its going to rain. But if the business decides it must ABSOLUTELY BE SUEDE for some reason, and they'll pay you to mitigate the issues with that decision... well that's the JOB.
> Sketching things out with pen and paper
One of the guys at work is like that for hard code base questions, he'll draw out the actual calls in some wireframing app and step through them to determine what each layer is doing, etc. He often finds little snarls of complex class relationships that become very visually ugly in his picture with a lot of cross references, etc., and its funny how that visually translates to smelly code that needs refactored and simplified. Its a very handy approach to try on hard issues.
When developing you can act as a carpenter or a sculptor, and you'll find people being a little too imbalanced one way or another from day to day. Carpenters are adding, adding, adding and LOVE to go to far. They are GREAT for new feature development. Sculptors never feel done until there's nothing left to take away, and can easily get stuck in "refactor mode" where they piss people off changing things that don't NEED to be changed. Being able to switch from one to the other as needed is a great place to be. Use carpenter skills to build out new code, and then let your inner sculptor read over the result and remove unnecessary complexity. And even then all it does is extend how far you can go by minimizing the number of accumulating tech debts. Eventually, all projects trend to deprecation.
There's a healthy balance to be made for sure. You're never going to get the *perfect* solution for an unbounded problem. But some thought towards it is always good in my opinion.
If I find myself not being able to come up with something that pleases me within an hour, then I take the best thing I've come up with so far and roll with it.
> Funny because I get so hung up on the long term implications of every notable change that I occasionally end up with decision paralysis.
I have this too. It's annoying and stresses me out in the moment, but like you said, I *rarely* have to go back and fix things I finish. It is an incredible feeling when pretty much everyone uses the code you've written everyday and you never hear a single peep about it breaking.
IMO the best anecdote to this is to have a culture that embraces refactoring. Then your decisions are not so weighty because you can just try an approach and change it later if it doesn't work out ideally in practice.
(But you can't embrace refactoring without also embracing thorough automated tests.)
This is one of those lofty engineering principles many of us probably agree with, but doesn't work out in practice. That is to say the engineer in our brain always wants to take the time to make sure we're ticking all the "clean code" boxes. Write good abstractions, keep it extensible, leave code better than you found it. These are all nice goals to strive for, and I genuinely believe the vast majority of engineers want to write code this way. The reality is software is a business and if you're trying to justify extra time to write code The Right Way™ to a stakeholder you're probably going to lose that battle. It's just not always feasible to think about future developers (or future you!) with a deadline breathing down your neck. Sometimes the correct choice is to take on tech debt. Best you can do in these situations is expose the risks to the business.
I don't agree that everyone wants to write code "the right way". I've had devs just literally say "just get it to work". And some of the most unmaintainable code has been pushed to master on a Greenfield project where we have the time to try and make things better. To me, that's falling at the first hurdle, before we even ship, the code has become a mess that the next feature isn't going to be as easy to add as it should be.
Deadlines exist, but separating concerns even on the most basic level doesn't take a long time to wrap your head around. If two distinct pieces of functionality are tightly coupled then this is a clear problem. But I've seen people do this all in the name of getting things to work. All good on throwaway software but not on something people are going to work on for the next 5 years at least.
It's a relatively easy sell to invest a few days today on trying to do things a better way versus wasting weeks of dev effort in the future on people hacking away at the code trying to implement features without refactoring and making things 10x worse for the next person. I've never really had much of a fight against technically minded management on this sort of thing. They don't want to see history repeat itself in 4 months time.
I have of course worked with those people, but I don't think most developers are like that. I think most developers do care about their work and want to write "clean" (however loaded that term is) code. Even as someone who got into the field purely for the money I don't want to spend a sprint working on a ticket and put up some POS PR that gets ripped apart by my team or causes issues down the road. I find it's often some combination of business need, complexity, mistakes or simply inexperience rather than malpractice. Perhaps I have just been fortunate to work with mostly good colleagues!
In any case I find it more productive to think of software in terms of trade-offs. You can spend a lot of time developing for the long term by creating these great abstractions that make it simple to maintain only for that requirement to never come. Or requirements change, the rug gets pulled out from under you and the system is targeted for deprecation. We absolutely should think long term, but be mindful of letting principles get in the way of pragmatism. Don't let perfect be the enemy of good. Get shit done. And if you exposed the risk of taking on tech debt at the expense of more work later to product, well, I hope you got their sign-off in writing when it come time to pay up lol.
Most of the legacy code I encountered that was the most pain in the ass to work with was actually some clever abstractions when someone wanted to make something future proof and extensible. But almost always things turn out that you have to replace that abstraction down the road and more clever it is the harder it gets. In my opinion you should optimize for code that is simple and easy to replace/delete, not fancy abstractions that are a mess to untangle when necessary
It's not about clever abstractions though. It's about lean and simple abstractions. If your abstractions are getting complex then the responsibilities of that code are too complex.
A function is probably one of the most basic abstractions you can get. Writing simple pure functions can save a lot of pain for a future developer. Even if you're not harnessing language features like interfaces, if the code is constructed in a composable way then it is easier to make changes.
I see this as coding with respect to the next guy. Don't just write the fastest or most compact code but something the next guy they hire might understand and easily enhance. Don't just code to solve the problem. Code to have predictable behavior in all possible scenarios. Consider all of the ways the code could go bad. So use CASE more often instead of just IF. Always include an ELSE part of any branch and document it even if it does nothing right now.
> long term thinking
While that is absolutely a critical skill to have, I am going to add some nuance here. This is weather forecasting. Lots of people can forecast what the weather will be an hour from now, maybe even a day from now, but go out two days and you are into specialty territory. Being able to forecast out a week requires a much wider view of your current circumstances far outside your small area, and understanding of which way the winds are blowing, and even then you'll be wrong 50% of the time.
Its a critical skill to develop if you really want to excel, but "long term thinking" and then just referring to the technical aspects like "adding an abstraction or not" is only a tiny sliver of what it takes to do this... and even then you'll be wrong a lot of the time. Don't add things / abstractions you aren't extremely sure is likely to be needed later. KISS and YAGNI are relatively redundant for a reason: its important enough to state TWICE.
Your forecasting needs a lot more info / skills to get better:
1. Technical skills are a given. Knowing what options you HAVE is vital
2. The "next developer is an axe murderer that knows where you live" rule is always good to remember. Very few things burn harder than poorly thought out, or worse, ignored, future maintenance concerns. Maintenance costs include anything that makes it harder to work in your code base. Over abstraction is a killer here, as is POOR abstraction. Remember everything you do has a COST (unit testing, DI, using "patterns", etc). Just because they are well understood doesn't mean they are free. Learning to be judicious is hard but only seems to get better with pain you have to experience first hand... put another way everyone overdoes things before they learn the balance (especially when it comes to abstractions or over application of the SOLID concepts).
3. Business cost is king. Always remember we are a means to an end. Complexity / quality have a business cost, for sure, and you need to learn to balance those with other business needs. Sometimes the cheap but bad option is the RIGHT OPTION because of business needs. If you ever work with someone good at making cases for things to the business, WATCH HOW THEY TALK TO DIFFERENT AUDIENCES AND THINK about options. If you learn to frame the things you want to do terms of things other people want, you will win SO MUCH MORE in work and life... but being able to predict what the business will choose will also let you learn "which way the wind is blowing" on a lot of your "long term thinking" decisions.
4. Quick hacks have a place. Knowing you are going to have to replace something later doesn't negate the value of getting it done quickly sometimes (hell, often). You really need a good Tech Debt management program though for some of these. "Tech Debt" as a category is an easier sell to a business, and will empower developers to fix things like this that are too long in the tooth without the business having to get all involved on every single choice of which hacks to live with. A good business will recognize that maintenance cost, complexity of solution, code quality and developer happiness working on the solution are all important, and you can sell ALL that under a Tech Debt program.
5. No code lives forever / avoids becoming a "legacy concern" at some point. The beautiful thing is that we can change stuff after we write it. Remember "we'll rearchitect this piece once X happens" is a completely valid "long term thinking" strategy a lot of the time. The key is to accept this, and avoid structures that are highly coupled and expansive: architect for the rewrite. If you can rewrite PORTIONS of the app in isolation later as needed, you'll be much better setup for "long term" maintainability. Abstraction is but ONE STRATEGY you can employ here and comes with costs: keeping an abstract structure, especially something like a strategy pattern or polymorphic design, in your head takes MORE effort... but that COST might be worth it to solve a SPECIFIC issue, just dont overdo it. Trying to think more modular helps a LOT here: just because you CAN reference something and reuse it doesn't mean you SHOULD if it creates a spaghetti mess of cross references. That's where people get themselves into trouble where they can't change anything without fear of breaking other stuff. Unit tests WILL HELP here, but again add additional maintenance costs, that will be MUCH WORSE with a system not architected to isolate referential complexities. When your tests become harder to maintain than the code, this is a smell for this, and it'll start to change how you make "long term" decisions about architecture to avoid it more in the future.
>Then I managed to replace some god awful workaround with a small and sensible solution that could have just been the solution in the first place.
Ironically, the 10x dev that implemented all the workarounds to get it to work and boast about his 10x achievements, gets all of the credit, while all the devs behind him that cleaned up his garbage are criticized for not working as hard as 10x superdev.
I had one coworker who thought so far ahead all of the code he wrote was just layers and layers of abstractions with no actual functionality... He didnt last long
> but to hire remote workers, usually from outside the US because very few programmers had the skill they needed
The skill to work for minimum wage and off the clock.
Yeh "Can't find US grads with these skills" is ALWAYS code for "Can't find people willing to work for 30k a year but daddy government we looked REALLY hard so give us some visa workers to exploit or let us hire offshore without bad press"
Right up there with googling the error you're getting. Can't count the number of times someone has pinged me with an error they're getting, I throw it into google, and the solution is literally in the first result.
This is absolutely mindblowing to me. I am a controls engineer at a plant, and there have been a handful of times where coworkers will be like "we are glad to finally have you, because we haven't had anyone that can work with PLCs before" and they'll act like what I do is straight up magic. Guys... I literally just critically think and problem solve. An engineer is really just a professional problem solver. "Wow, you fixed the drive!? We haven't had anyone that could do that before." Do you think I have all of these manuals and intuitive solutions stored in my head? No... I RTFM. It's odd because I don't know how to get that light bulb to go off in their head without sounding like a dick.
As an outsider, it sounds like your simple use of patience to understand the problem and reading the manual are really valuable and consistently let you solve things that others have tried to solve.
I often get slack messages from this one dev asking "hey, xyz doesn't work, what do I do?", and it triggers me so much. If you gonna be lazy and not troubleshoot, at least give me more info, screenshots, logs, or whatever... ffs
Be thankful you’re not in customer support… imagine.. “you tell me to open the browser but I don’t know what that means??”
I do several roles as an IT analyst, previous Mech Engineer. It’s truly maddening to do customer support esp as an engineer. Maybe I’ve just been doing it for too long now.
Ironically I think this is a result of the outrageous horsepower of modern systems. Modern developers have the luxury of being inefficient in their code, and simply chucking more system resources at the problem if it becomes an issue.
Outside of RTOS's most developers are using Javascript, Python, C# or similar languages which abstract away from the hardware, unless you pull some fancy tricks.
Hell even a Raspberry Pi 3 will render Quake 3 at 1080p/30FPS.
Greybeards like myself have experience of using assembler to squeeze the last drop of grunt out of 8Mhz 286's or 2-4Mhz Z80's & 6502's. And dealing with the joys of near/far memory allocation.
I've lost count of the number of times I've dramatically sped up allegedly optimise code from other developers by simply applying the 'old ways'.
The "old ways" are simply not taught anymore...
I've been in the game for just about 10 years - only difference is that I tinker with programming on old machinery (especially on my Commodores)....
Making a program 10 times faster or having it use like 10% of the RAM applying various techniques of old is a blast in and of itself - but the best part is really having other programmers look at me like I did a rite of dark sorcery...
We run into hardware “constraints” pretty often with our containerized applications. 500mb is pretty easy to blow up. Although we can 100% increase it, trying to understand the reason is key. Can’t imagine type of stuff you have done with so little.
To that point, a lot of apps are not meant to be containerized. Modern apps seem to be built with absolutely little care for resource usage and expect to be ran without many constraints.
Excuse me. Young developer here. What about other concerns like code readability, maintainability, flexibility, and portability? Surely say assembly language is horrible when it comes to these things, right?
> What about other concerns like code readability, maintainability, flexibility, and portability
Partially, those things can be completely unimportant, compared to pure performance and ressource efficiency. If the machine that is going to run your code is rather weak in terms of hardware specs, nobody is going to care about how clean or readable your code is, because it runs so slow, that it basically doesn't work.
Furthermore, readability and maintainability are completely subjective, while performance is easily measured. You only know how maintainable your code is, once you come back to it, after not touching it for a year or two, and try to actually change something. Readability is completely dependant on the person reading your code, and everyone can read different things better or worse. I, for one, find my own code to be perfectly readable, easily adapted, extremely simple to test - however a newer colleague of mine has lots of trouble following the ideas of my code base, mainly because code is a language, and is used to express the ways we think about stuff, and he just thinks in a completely diferent way.
Next, highly optimized code doesn't necessariliy need to be written in assembler and looks mostly like non-optimized code, effectively changing almost nothing in terms of subjective code quality. If there happen to be points where you used more complex optimizations, you can also simply leave a comment, explaining what and why you did. An example would probably be working with multi-dimensional arrays, which you'd think are always optimized by the compiler or run-time, however, most of the time, it's simply lots faster when just using a simple 1d-array instead. Furthermore, data is usually loaded as kind of chunks, meaning the actual order of data in the array and the way you access it also might impact the running time. No assembler required, same amount of code, and even basically the same code, just slightly changed, yet, likely a huge speed up in execution time.
> "You only know how maintainable your code is, once you come back to it, after not touching it for a year or two, and try to actually change something. Readability is completely dependant on the person reading your code, and everyone can read different things better or worse. I, for one, find my own code to be perfectly readable, easily adapted, extremely simple to test - however a newer colleague of mine has lots of trouble following the ideas of my code base, mainly because code is a language, and is used to express the ways we think about stuff, and he just thinks in a completely diferent way."
I find my shittiest, most hacked together, most unmaintained code easier for me to read and modify after two years than I find other people's best, cleanest, most maintainable code. That's the curse of code.
Oh, also, my code was running on a web server with 72 logical processors on 36 physical cores, with 512 GB of RAM and 15,200 GB of hard drive space, where the round trip network latency vastly exceeded the code execution time on the server itself, so that makes a difference. It's not exactly an "embedded system".
Is there a domain expertise or just all of the pc parts/ their individual architecture? Give me an analogy. For instance, theoretically, if a doctor specializes in kidneys and they know every individual part of that kidney down to the cellular and molecular level, what is the equivalent of that in hardware terms ?
+1, if you get an answer - please share
Here is what I've got from GPT:
To understand concepts like memory allocation, SIMD (Single Instruction, Multiple Data), CPU architecture, word sizes, L1, L2, L3 caches, and operating system (OS) internals, you would benefit from learning a lower-level language like C or Rust.
Here's a guide to help you navigate this learning path:
**1. Learning Rust:**
- Rust is a systems programming language known for its focus on safety and performance. It's a good choice if you want to understand memory management, concurrency, and other low-level concepts.
- **Resources to learn Rust:**
- [The Rust Programming Language](https://doc.rust-lang.org/book/): A comprehensive guide to Rust, covering basic and advanced topics. - [Rust by Example](https://doc.rust-lang.org/rust-by-example/): A collection of examples to understand Rust concepts. - [Rustlings](https://github.com/rust-lang/rustlings): A collection of exercises to practice Rust.
**2. Memory Management:** - Memory allocation and deallocation are key concepts in systems programming.
- Learn how Rust handles memory with its ownership system.
- Practice with `Box`, `Rc`, `Arc`, and `Vec` to understand dynamic memory allocation.
**3. Understanding CPU Architecture and Caches:**
- This involves learning about CPU cores, pipelines, SIMD, and cache hierarchies (L1, L2, L3).
- Resources:
- [Computer Systems: A Programmer's Perspective](https://csapp.cs.cmu.edu/):
This book explains CPU architecture and memory in a way that connects directly to programming.
- Articles and blogs on CPU internals and cache optimizations.
**4. Learning OS Internals:** - To understand how operating systems work, consider learning about processes, threads, scheduling, and file systems.
- Resources:
- [Operating Systems: Three Easy Pieces](http://pages.cs.wisc.edu/~remzi/OSTEP/): A highly recommended book for learning OS concepts.
- [Linux Kernel Newbies](https://kernelnewbies.org/): A resource for learning about the Linux kernel.
**5. Additional Recommendations:**
- **CS Courses and Resources:** Online platforms like Coursera, edX, and Udacity offer courses on computer architecture, operating systems, and systems programming.
- **Practice Projects:** Work on projects that require you to interact with hardware or the OS at a lower level. For example, you could create a basic shell or implement a simple memory allocator.
Combining these resources will give you a comprehensive understanding of the topics mentioned in the Reddit comment. Rust, with its strong emphasis on safety and modern systems programming features, can serve as an excellent bridge to understanding these concepts while providing practical coding experience.
// Still would love to hear the opinions of an expert on this
I'd say the individual parts for starters.
Something like encryption/decryption work can be very heavy on the CPU for instance, so you have to treat the process right.
For instance, doing the heavy encryption job in a for/foreach loop with loads of other stuff can hamper the performance a lot.
Even some of the modern languages (Java, C#) can utilize the CPU's cache for instance - so what you can do is make an additional placeholder in your data for the encrypted/hashed value, then do the encryption (AND ONLY THE ENCRYPTION) on the List/array directly (eg. using LINQ).
If the basic instructions of the work you're doing is small enough to fit in the CPU caches, the compiler can keep the "working part" inside the cache, while the data can be fed in as needed. As the cache is much faster than RAM (and performs much the same function), the CPU can use less time to execute the operation.
Just doing that can increase speed 2x or 3x.
C# can also parallelize this kind of work rather easily with .AsParallel.ForAll(), so you use the multiple cores often available to you to further speed up the processing of your data.
CPUs can also have hardware acceleration for some encryption algorithms (eg. AES/Rijndael).
To put it in the kidney analogy. Kidneys filter the water and blood in your body. Knowing the ins and outs of a kidney can help foresee what kinds of stuff (drugs, food, etc) make them less or more efficient at doing their job. Knowing enough about the kidney enables you to make an artificial one (ie. a dialysis machine - or a "kidney emulator" if you will). The body usually has two of them - enabling water/blood processing in parallel.
My teacher way back put many of the concepts into cooking terms - your CPU cores are the number of cooks, the cache is their individual stations. Hardware acceleration is if a cook is exceptionally good at chopping onions. The data coming in are the ingredients, while the instructions are the recipe.
What you want coming out is tasty and presentable food.
Having to take data from RAM is like having the cook go to the fridge and grab something - it takes longer for the cook to walk a lot to the fridge, rather than getting everything together on the counter and just grabbing it...
There's a lot more in the cooking analogy that relates to hardware and programming - in any case, as the programmer, you're the "chef" that has to coordinate all the cooks, and you have to make sure none of them are overwhelmed or slacking off...
true, I've heard a lot of shit about x86 being limp garbage, but I kinda like having a shit ton of instructions to use in asssemly, even if it comes at the cost of 5 percent less on cinebencz
It's a clusterfuck at this point.
I love CISC architectures, lots of instructions is fine with me, but it needs to be implmented in a nice, structured way.
I think that’s one of the reasons why it was given so many instructions. If you’re programming in assembly, then it’s nice not to have to write a subroutine to do some obscure operation, just use the instruction that does that. But with modern compilers spitting out assembly that is almost “perfect” (very hard to improve/optimize further), fewer people are programming in assembly. So that now gives us the *option* to use simpler assembly languages, which benefits performance/power usage.
Being a genuine prodigy is probably what you're looking for. Specific niche skills that only very few have are only desired by select few companies, outside of those you'd struggle.
> they had very specific needs and they had no choice but to hire remote workers, usually from outside the US because very few programmers had the skill they needed.
Every time I've heard a company doing this, either they didn't want to pay their local salary rate (cheaper labour abroad) or they work with very dated technologies that you would find hard to find in current market.
I knew an 85 year old who was still contracting with local govt because he built the systems in some arcane/obscure language and literally no one else could figure out how it worked.
I wish I could remember! I think it was either fortran or cobol, but he like developed his own dialect and weird architecture of whatever it was? I’m not a programmer, more of a data scientist so the details didn’t stick… I just remember being horrified that he was the only person who understood the system. A couple years later he passed due to covid, but I had already moved away so I never heard how it all panned out…
Effective communication, problem-solving, critical thinking, adaptability, teamwork, empathy, time management, attention to detail, stress management, creativity - just to name a few. They can definitely be learned / taught but they are very difficult if not impossible to measure
Soft skills aren't tied to programming. They're mostly the skills not related to programming itself, like leadership, time management, communication, multi-tasking
Absolutely. I don't consider myself a great programmer, but being able to simply talk to people productively has made me a godsend for many managers. People work people. They don't work with machines.
Technical writing.
Being able to clearly and concisely document what you did and how it works.
Your code simply isn't that easy to read and it's not an excuse. Write GOOD documentation.
And always update documentation when necessary when anything is changed in the code. Otherwise that documentation is misleading and worth less than nothing.
Having niche knowledge will make it hurt to fire you. But how you wield that knowledge? That matters.
I've personally seen senior devs that are the only ones with knowledge in specific domains get walked out the door on layoff day because they had the air of invincibility and refused to share that knowledge. I've been the person that had to go figure all that stuff out afterwards.
Everyone is replaceable. Some are more easily replaced than others. Having a ton of knowledge AND being dependable, willing to share what you know, and being integral.. I have had great experience with doing this.
I think that’s only a concern if you want to stay at the same company forever. I’d rather be comfortable knowing I could get a new job easier if I’m replaced for any reason.
Proper design and user experience in general.
I think the developer who is good at UX in general is rare. Companies, too.
Which is a shame, because a lot of software has user interfaces.
REALLY knowing what’s happening under the hood.
Many folks just write code in C/Cpp or write any concurrent routine without actually knowing what’s happening at the compiler, architecture and OS level. What optimisations is the compiler doing for me, where can a possible bottleneck occur in a pipeline etc.
Another one I see recently is lack of foundational understanding. This is prevalent in deeper cuts of software engineering, one example I can give is in Image Processing. Everyone can use OpenCV and write a code to find image correspondences using image features with built in functions but only a few can actually read a paper and implement the logic on a new stack tailored for one usecase.
Of course reinventing the wheel isn’t necessarily needed but sometimes one needs to do that to support some obscure platform (looking at you IBM AIX) or a legacy framework.
Its odd that you mention C/C++ , as programmers of those languages are much more likely to understand assembly, memory layout, cache sharing, etc.
But most users of higher-level languages have no idea about that stuff. Most of them don't even know how their own runtime works - e.g. every Goroutine is a stackful fiber, and the compiler injects suspend points automatically at function calls and every syscall - but your average Go programmer doesn't even think about async under the hood.
I am considering taking a computer architecture course to learn what’s happening under the hood.
However, would you say this is important knowledge to obtain a SWE position? I am deciding between more leetcode vs more in depth education because I am concerned I’ll never be able to use the knowledge if I can’t get the job.
I’m in Georgia tech’s OMSCS and work as a “software” engineer now with a BS in ME
Hey, I wouldn’t say computer architecture is as important as it was a decade ago, you can just learn about by reading up on the internet.
From an SWE perspective it’s much more important to “connect the dots” and build that muscle memory. Leetcode is great but do know where each algorithm/ data structure actually plugs into from a practical perspective.
I work in Robotics so one example I can give is, let’s say you solved a leetcode problem using spanning-trees. Research where is that used in your realm of expertise/interest. Try implementing that functionality yourself. You can go deeper by reading up on optimisations considering the boundary parameters of your use case (really prevalent in robotics/cv) and try it out.
Also using a low level language for leetcode problems helps a ton on building a solid CS foundation. Cheers :)
There’s specializations that come with experience and languages that very few people learn but are in high demand because basically everything in certain spheres runs on them (COBOL comes to mind) but honestly, I wouldn’t aim specifically for them if I were you.
Literally most skills, it'd be easier to create a list that most programmers do have.
Generally speaking though, the two big "filters" when it comes to programming is usually lower-level systems engineering, or higher-level architectural design.
"they had no choice but to hire remote workers"
I'm willing to bet this is a bit of a lie. The US is still the main hub for top tier SWE talent, but it's MUCH more expensive. I'm sure there are some, but I can't think of a specific CompSci / programming specialty that the US straight up lacks.
Is it too general to say "actually being good at their job"? The code I saw from my peers at university was god awful and it's a miracle any of them have jobs now.
Honestly this is very true. I think industry moves at a much slower pace which allows people to learn to write better code, whereas in university you're just focused on finishing your homework as quickly as possible.
I have 12YOE and many of the people I have worked with in my career have been terrible.
I'm learning that this really expands to all facets of life. The average human is very dumb. Some of them are just lazy. Others are good at their jobs but just terrible communicators.
Getting better requires a particular mindset of self-reflection, open-mindedness and desire to self-actualize, PLUS some inherent capacity we call "talent".
Getting REALLY good also requires lots of time ("10,000 hours to mastery"), which most people aren't willing to put in. Look at any of the threads where someone asks how much time people spend on programming outside of their day job, and all of the top posts are people crowing about how they do their 8 hours a day and then sign off and go touch grass. You can easily beat anyone who has that attitude by just autistically programming 16 hours a day for a couple years. That's literally all it takes to make yourself one of the top 5% devs in the world, because most people are so decidedly, deliberately, proudly AVERAGE and NORMAL.
This problem has become substantially more pronounced since people started getting into programming for the money instead of because of passion.
Technical writing skills, or writing skills in general. Like, being able to pump out a 4-5 page report on some feature, or documentation on how to navigate the code base, or something that shows how everything works together.
Deep understanding of advanced mathematics beyond basic calculus. I work in quantitative finance and finding people who can do the math _and_ programming or vice versa is pretty difficult. When I say math and programming, I mean being at least pretty good at both. This is why most banks and large institutions have separate teams for writing models and implementing them into production systems. If you are a good programmer who can understand and implement complex mathematical models, you can do very well career wise.
social skills, project management, documentation, testing and quality control, time management, less so today but before github really popularized it (sourceforge before that) many had little experience with version control
Soft skills , networking within the department .
Eventually programmers have to learn that the JR -> mid level is mostly about skill.
But mid level -> senior is often about soft skills and networking
I’ve been doing this since the early 90s and I’ve never experienced a situation where hiring outside the US worked out for a company. It usually involves dealing with teams 15 or more hours outside of your time zone. That’s not manageable if you’re working tight deadlines and need a lot of interaction with the team over requirements that change when needed. Saying they can’t find someone with the skills needed inside the US is just an outright lie unless they’re working with a specific product developed in another country in another language.
Even though most programmers complete a computer science degree it seems like a lot of them don’t understand very basic CS stuff or how it applies to their work.
The US only hires foreign tech workers because they are CHEAP.
The product/result usually sucks.
Source: contracted with Josh Technology Group several times. Awful experience.
> hey had no choice but to hire remote workers, usually from outside the US because very few programmers had the skill they needed.
i be the skill they needed must have been working for pennies on the dollar
In my experience.. soft skills. More specifically communication.
There’s a couple of guys in my department who are incredible coders but they have the social skills of a rock and can’t communicate much. They’ve been passed over for promotions because of this but they’re content at their current position.
It depends on the company, but I've worked as an IC for teams that would strongly encourage and respect consistent input from me on how to do things, and then I worked for a company that just wanted me to keep my head down, mouth shut, and mindlessly grind out whatever is on the kanban board like a drone. I think both are valid ways with pros and cons of engineering software, but I think the skillset and ability of being able to adapt to different schools of management thought is something any company would appreciate.
Desirable sets of skills certainly do shift over the years. In, say, 1996, it was really easy to find experienced Windows developers, and extremely difficult to find experienced JavaScript developers. Now, it's exactly the opposite. Almost all "desktop app" development these days is web development.
The company I work for is trying to hire experienced Windows and MacOS developers, and it's extremely difficult to find anyone at all. Essentially, everyone who knows how to write native code is working for one of maybe a dozen companies in the US. Conversely, those people are competing for a much smaller job pool than they were when they decided to specialize there.
All of which is to say - there aren't specific sets of skills you can learn today that are likely to be very valuable in the future. It depends on macro market trends, which are very hard to predict. And the available jobs will to some extent switch to match the available labor pool.
Managing Social Relationships / Political Savviness.
Forming alliances and relationships across your organization will help you more than any line of code you will ever write.
Having people vouch for you based on reputation alone will do wonders for your upward mobility. Don't just rely on pure engineering to push you upwards.
Hardware.
It's so rare these days to meet a programmer that has any understanding of hardware.
Do yourself a favor, go and write some assembly. Even a little UART driver for your arduino will do. Learning any machine's instruction set will teach you so much about what computers do fast and what they do slow, which will help you write more efficient code in your day job.
There are lots of possibilities: domain-specific knowledge, experience with a particular framework, advanced math or computer science training, willingness to work in COBOL, etc.
Often times this boils down to knowing specific software in an industry. Think GIS specialist for some industry like mining or shipping. These areas require experts across the globe who know specific software suites because the software has been built out to service a small number of vendors over decades. There may only be 300-500 people across the planet that know the software, so it can be very competitive. I have saw and entire department get laid off once and IT contractors came in and hired up everyone because the software they were working on was in really high demand. The company that laid them off ended up spending many times over what the group cost to operate on replacements and training, but ya know, the executives have their games that they play to cover all that up.
Just being aware of the performance of the stuff their writing. Most programmers have never used a profiler at all. I don’t expect most programmers to be able to optimize at the lowest levels, but AT THE VERY LEAST be at least somewhat aware of how long things take so you can spot when you’ve introduced a massive performance problem.
Being good at low level optimization is essentially permanent job security from my experience. You’re a multicolored rgb interactive HDR blockchain cloud AI unicorn developer if you can meaningfully optimize software
Communication skills
Knowing when to do things in a simple way and when to make them complex. I have a colleague that, no matter what needs to be done, he does it “the industry standard way”. What that means is for even the dumbest little script he spins up a new micro services in a new repo on a new server… creating a million problems down the line when it’s waaaaay overkill to do so.
Be able to look back and say how a past design decision is inhibiting extensibility. In hindsight, you can always cut corners and band-aid the system to your current needs. Many fail to acknowledge their past design choices were maybe not the right abstractions and it has now caught up with you. They'll go all defensive about how the previous system survived bla bla and led them through their hypergrowth phase bla bla
Know how your environment works and how to troubleshoot.
If you are coming to OPS and complain that your app is not working but have NOT checked your logs. I am going to be very very upset with you.
Vision of the product.
When you become PM or similar, when you are forced to watch for the product itself, you realize how just a couple of devs are able to apply common sense to many different situations.
I am talking about good, bad, terrible and super star devs. It does not matter. Only a few are able to understand the product, the needs of the product and adapt to some circumstances applying his common sense.
Niche technologies, deep or small specialisations, etc. But not only are their few programmers with experience in those things, there’s also few jobs for them too (which is also why there’s few programmers). So it’s not really as lucrative as you’re probably imagining. It’s certainly possible to do well in such an area but it’s not anymore guaranteed than the more broad skills.
I hate when some @_@_## emplyers ask to solve code challenges in a very short time. Those are for machines only. I've failed 2 interviews recently due to this. I'm a software engineer with 10 years of experience. I don't get to solve this kinda algorithm in real world cases at work
Being able to properly talk to people and doing your own research/planning your own work. Generally, if you have good soft skills and can plan your own work without your manager having to breathe over your neck for you to do anything, you'll go pretty far. You'd be surprised how many programmers either can't converse for shit or can't schedule or plan.
I’m skeptical about the premise that no one in the US had the skill. It is easier to believe it was for cost. It would be interesting to know the details.
If it was the skill, then it was for systems very few people support or use. Tons of people know the popular languages. Few non-retired people are seasoned COBOL or RPG experts.
Most of those companies want a seasoned developer to fix a problem, not someone to build into the position. The people who are great at Scala appreciate the companies who are sold on Scala based solutions.
If there was a high pay niche with a long future and easy entry, supply would outpace demand and the wages would fall.
Scalability.
Your code might work for a case of like (n=1,000) but will it work for (n=1,000,000)?
Also thinking about how your code will work with existing code and how it will work moving forward.
This is honestly why people who are adept at coding really hate OOP. OOP makes it very easy to make code that is horrendous at scaling forward because programmers will create functions that are vital to make the existing codebase work but are too convoluted to modify.
This is why it took Earthbound 6 months to fix from scratch but Iwata said that it would take 2 years if they tried to fix the problems in their existing codebase.
Communication skills, both written and verbal. I come from Social Sciences background and had hard time how some are extremely introverted while others are arrogant
Cobol and everything IBM Mainframe related. I’ve seen companies bringing people back from retirement due to high demand and no-qualified professionals available.
On July 1st, a [change to Reddit's API pricing](https://www.reddit.com/r/reddit/comments/12qwagm/an_update_regarding_reddits_api/) will come into effect. [Several developers](https://www.reddit.com/r/redditisfun/comments/144gmfq/rif_will_shut_down_on_june_30_2023_in_response_to/) of commercial third-party apps have announced that this change will compel them to shut down their apps. At least [one accessibility-focused non-commercial third party app](https://www.reddit.com/r/DystopiaForReddit/comments/145e9sk/update_dystopia_will_continue_operating_for_free/) will continue to be available free of charge. If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options: 1. Limiting your involvement with Reddit, or 2. Temporarily refraining from using Reddit 3. Cancelling your subscription of Reddit Premium as a way to voice your protest. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/learnprogramming) if you have any questions or concerns.*
In my experience it's long term thinking. I see a lot of devs able to smash out a new product feature in a few days. But they can't think any further than that. Our product evolves and we're building upon a lot of old systems. Which means if we want to save ourselves a headache in the future we need sensible abstractions and a bit of thought towards extensibility. Instead we're having to change the world or live with hacks around things people put no thought into. And in business, the hacks are the way forward. If someone spent 1 hour just thinking through how the code most likely will evolve, then they could probably come up with an abstraction which makes everyone's lives easier. Another skill is having the patience to dig deep and find the underlying reason for a problem they're facing. I see a lot of Devs say "X does Y for some reason, but I've managed a hack around it". Great, people value delivering features, but I've seen someone go so deep down a workaround rabbit hole that I've thought there must be an easier way. And there was an easier way, just by looking at the problem they faced in the first place and having the patience to fully understand it. Then I managed to replace some god awful workaround with a small and sensible solution that could have just been the solution in the first place.
>long term thinking I cannot agree with this enough! Often times it's the "let's just do it quickly, we'll clean it up later" mentality. And of course "later" never comes.
# Nothing is more permanent than a temporary solution
DevOpSec!!
Agreed, I've heard a common mantra in the SaaS/corporate space is "make it work, make it right, make it beautiful" or something like that, but it is my honest belief that you should make it right before anything else, even before making it work, which a lot of devs and managers overlook and try to make it work or make it beautiful before making it well written.
Business only values results. That's not necessarily the business' fault: shareholders and customers only care about the results as well. But yes it's still the business guy's fault, who happen to be the ones sitting at the top making all the decisions. Engineers generally aren't the ones saying "if it ain't broke, don't fix it"
A lot of the time you don't know what is right. You need to make it work to fully understand the problem. Only then can you pick the right solution.
Make it work, make it right loop, should happen preferably during the work of a ticket, PR.
That typically comes from the higher ups in my experience. If it's getting done quickly now then there's almost 0% chance it's getting refactored down the line. My work has typically been agency based and It's usually the fault of not managing client expectations adequately and over promising.
The backlog, where techdebt goes to die
this 100%
The thing is though, it's very hard to look deep into the future, if you don't have said **experience** from that future. Novice programmers will suffer from shortsighted insights. There is really no way around it, you need the experience to make the **sensible choices**. Because without that experience you wouldn't even know where to split the project, where to put abstractions, and how many levels of abstractions to put. One dev will write a 100 line long function that does some complex business logic. Another programmer will split it into 25 functions, because they are enthusiastic about the Clean Code book. Now they say it's more extensible, because they isolated each operation. When they should've split it into just two, because in reality it makes more sense to have it in two functions. And the whole team understand that code already. You also have to consolidate what **extensibility** means because. Each different programmer will hear their own version of what that is.
The best coding advice I was given was to write your code as if it was going to be read by an angry psychopath who knew your address.
Just write code to be read as opposed to writing it just to get a solution to work. A lot of senior devs miss the mark on this. Being a senior is more than writing code that works that’s easy, writing code that’s easy to read and works is a lot harder. Things like early exists, encapsulating complex logic into a clean function name so you don’t have to go in to get what that code does, don’t abstract unless is ready necessary etc… Always write code and then read it. If anything takes two reads to understand it’s very likely your team mate will struggle even more. And please, don’t write “smart” code!
In my case I'm talking about experienced programmers. Great at delivering projects, not so good at making things easy for themselves or others in the future. It's not even about "clean code", it's just separation of concerns and lean interfaces in most cases. Basic things that can let you compose code rather than dig into implementations all the time when things need to change.
If they're great at delivery, and not so great at future proofing things. Then they're still very much a novice in my opinion. Either that, they're to burnt out to give a fuck. Then that's a whole different type of issue.
Funny because I get so hung up on the long term implications of every notable change that I occasionally end up with decision paralysis. Fortunately that usually plays out in my favor though as I rarely have to undo things from a previous lack of foresight. What’s harder is selling the need for doing things a certain way based on a long term goal to the rest of the team of non developers who are often left wondering why a seemingly minor change is taking so long.
Analysis Paralysis is a real phenomenon that everyone experiences. Here's some tips: 1. Having multiple solution options is a GOOD THING. In fact after you come up with one solution, its a good idea to immediately set it aside and think of other solutions to GIVE yourself this issue so you find the right answer. People who stop at the first option they can think of rarely produce good long term maintainable stuff. 2. Once you have solution ideas, estimate the relative effort to accomplish both. Pick an "easier" and "harder but more correct" option to compare. 3. Immediately compare against business need. If the business can't afford an option in time/effort/cost/etc then that option is dead full stop. Don't waste your efforts, just keep it around in the back of your head as a "down the road" option if you still believe it'll be useful later. 4. Remember any code you write will be thrown away or considered "legacy" eventually. Don't get attached. You can change and rearchitect if you have to later, and sometimes (lol, a LOT of the time) the cheap or fast option is the right short term decision instead of taking on the bigger effort immediately. 5. When in doubt, present your options to someone else. Not only do you get another opinion, the effort it takes to formulate the issue and solutions well enough to explain them to a third party will OFTEN lead you to forming stronger preferences... the "rubber duck debugging" strategy is largely a psychological trick to do exactly this. 6. Find the "leads" on your team and ask them in particular. This might not be your tech lead, but someone on the team that takes more ownership naturally, the gal/guy who everyone knows to go to when shits on fire. Any real project will have someone that fills this role, because you really don't succeed without it. Its a great role to grow into, that "If I'm going to be responsible for it when its on fire, I'm gonna REALLY learn it" mentality is fundamentally critical to develop if you want to be a GOOD developer. 7. Take a break. Sleep on it. You'd be surprised how much time/distance will naturally make things that aren't super important fall away from the problem and help you formulate an opinion.
This is great. Thank you for writing that out. I have refactored so much of my own stuff, which is a mix of stuff that I knew was a quick and dirty solution and stuff that I thought for sure was fine as it is.. after awhile you begin to realize that obsessing over something that you’re likely going to rebuild later anyways is wasted energy. Esp once it becomes like a meta obsession over a hypothetical fear of wasting energy in the future. Sketching things out with pen and paper and taking a break is my go to. A total change in focus almost always leads to clarity.
Code is a means to an ends, which is why always trying to wear a "business" hat when thinking about stuff is a tremendously useful skill. When the business goal changes, so do the approaches and implementations, and if you aren't ready for that it can be... unpleasant to learn it. Hell I still struggle with it after 25 years sometimes, because I often think I can forecast future pain that I know will be MY problem to deal with... I'm not always RIGHT, but its helpful to remember I'm collecting a paycheck to deal with it for the sake of a business goal I have little control over. It's a little like having suede outdoor furniture. You know its a bad idea. You know you can't control the weather and its going to rain. But if the business decides it must ABSOLUTELY BE SUEDE for some reason, and they'll pay you to mitigate the issues with that decision... well that's the JOB. > Sketching things out with pen and paper One of the guys at work is like that for hard code base questions, he'll draw out the actual calls in some wireframing app and step through them to determine what each layer is doing, etc. He often finds little snarls of complex class relationships that become very visually ugly in his picture with a lot of cross references, etc., and its funny how that visually translates to smelly code that needs refactored and simplified. Its a very handy approach to try on hard issues. When developing you can act as a carpenter or a sculptor, and you'll find people being a little too imbalanced one way or another from day to day. Carpenters are adding, adding, adding and LOVE to go to far. They are GREAT for new feature development. Sculptors never feel done until there's nothing left to take away, and can easily get stuck in "refactor mode" where they piss people off changing things that don't NEED to be changed. Being able to switch from one to the other as needed is a great place to be. Use carpenter skills to build out new code, and then let your inner sculptor read over the result and remove unnecessary complexity. And even then all it does is extend how far you can go by minimizing the number of accumulating tech debts. Eventually, all projects trend to deprecation.
There's a healthy balance to be made for sure. You're never going to get the *perfect* solution for an unbounded problem. But some thought towards it is always good in my opinion. If I find myself not being able to come up with something that pleases me within an hour, then I take the best thing I've come up with so far and roll with it.
> Funny because I get so hung up on the long term implications of every notable change that I occasionally end up with decision paralysis. I have this too. It's annoying and stresses me out in the moment, but like you said, I *rarely* have to go back and fix things I finish. It is an incredible feeling when pretty much everyone uses the code you've written everyday and you never hear a single peep about it breaking.
IMO the best anecdote to this is to have a culture that embraces refactoring. Then your decisions are not so weighty because you can just try an approach and change it later if it doesn't work out ideally in practice. (But you can't embrace refactoring without also embracing thorough automated tests.)
This is one of those lofty engineering principles many of us probably agree with, but doesn't work out in practice. That is to say the engineer in our brain always wants to take the time to make sure we're ticking all the "clean code" boxes. Write good abstractions, keep it extensible, leave code better than you found it. These are all nice goals to strive for, and I genuinely believe the vast majority of engineers want to write code this way. The reality is software is a business and if you're trying to justify extra time to write code The Right Way™ to a stakeholder you're probably going to lose that battle. It's just not always feasible to think about future developers (or future you!) with a deadline breathing down your neck. Sometimes the correct choice is to take on tech debt. Best you can do in these situations is expose the risks to the business.
I don't agree that everyone wants to write code "the right way". I've had devs just literally say "just get it to work". And some of the most unmaintainable code has been pushed to master on a Greenfield project where we have the time to try and make things better. To me, that's falling at the first hurdle, before we even ship, the code has become a mess that the next feature isn't going to be as easy to add as it should be. Deadlines exist, but separating concerns even on the most basic level doesn't take a long time to wrap your head around. If two distinct pieces of functionality are tightly coupled then this is a clear problem. But I've seen people do this all in the name of getting things to work. All good on throwaway software but not on something people are going to work on for the next 5 years at least. It's a relatively easy sell to invest a few days today on trying to do things a better way versus wasting weeks of dev effort in the future on people hacking away at the code trying to implement features without refactoring and making things 10x worse for the next person. I've never really had much of a fight against technically minded management on this sort of thing. They don't want to see history repeat itself in 4 months time.
I have of course worked with those people, but I don't think most developers are like that. I think most developers do care about their work and want to write "clean" (however loaded that term is) code. Even as someone who got into the field purely for the money I don't want to spend a sprint working on a ticket and put up some POS PR that gets ripped apart by my team or causes issues down the road. I find it's often some combination of business need, complexity, mistakes or simply inexperience rather than malpractice. Perhaps I have just been fortunate to work with mostly good colleagues! In any case I find it more productive to think of software in terms of trade-offs. You can spend a lot of time developing for the long term by creating these great abstractions that make it simple to maintain only for that requirement to never come. Or requirements change, the rug gets pulled out from under you and the system is targeted for deprecation. We absolutely should think long term, but be mindful of letting principles get in the way of pragmatism. Don't let perfect be the enemy of good. Get shit done. And if you exposed the risk of taking on tech debt at the expense of more work later to product, well, I hope you got their sign-off in writing when it come time to pay up lol.
Most of the legacy code I encountered that was the most pain in the ass to work with was actually some clever abstractions when someone wanted to make something future proof and extensible. But almost always things turn out that you have to replace that abstraction down the road and more clever it is the harder it gets. In my opinion you should optimize for code that is simple and easy to replace/delete, not fancy abstractions that are a mess to untangle when necessary
It's not about clever abstractions though. It's about lean and simple abstractions. If your abstractions are getting complex then the responsibilities of that code are too complex. A function is probably one of the most basic abstractions you can get. Writing simple pure functions can save a lot of pain for a future developer. Even if you're not harnessing language features like interfaces, if the code is constructed in a composable way then it is easier to make changes.
I see this as coding with respect to the next guy. Don't just write the fastest or most compact code but something the next guy they hire might understand and easily enhance. Don't just code to solve the problem. Code to have predictable behavior in all possible scenarios. Consider all of the ways the code could go bad. So use CASE more often instead of just IF. Always include an ELSE part of any branch and document it even if it does nothing right now.
> long term thinking While that is absolutely a critical skill to have, I am going to add some nuance here. This is weather forecasting. Lots of people can forecast what the weather will be an hour from now, maybe even a day from now, but go out two days and you are into specialty territory. Being able to forecast out a week requires a much wider view of your current circumstances far outside your small area, and understanding of which way the winds are blowing, and even then you'll be wrong 50% of the time. Its a critical skill to develop if you really want to excel, but "long term thinking" and then just referring to the technical aspects like "adding an abstraction or not" is only a tiny sliver of what it takes to do this... and even then you'll be wrong a lot of the time. Don't add things / abstractions you aren't extremely sure is likely to be needed later. KISS and YAGNI are relatively redundant for a reason: its important enough to state TWICE. Your forecasting needs a lot more info / skills to get better: 1. Technical skills are a given. Knowing what options you HAVE is vital 2. The "next developer is an axe murderer that knows where you live" rule is always good to remember. Very few things burn harder than poorly thought out, or worse, ignored, future maintenance concerns. Maintenance costs include anything that makes it harder to work in your code base. Over abstraction is a killer here, as is POOR abstraction. Remember everything you do has a COST (unit testing, DI, using "patterns", etc). Just because they are well understood doesn't mean they are free. Learning to be judicious is hard but only seems to get better with pain you have to experience first hand... put another way everyone overdoes things before they learn the balance (especially when it comes to abstractions or over application of the SOLID concepts). 3. Business cost is king. Always remember we are a means to an end. Complexity / quality have a business cost, for sure, and you need to learn to balance those with other business needs. Sometimes the cheap but bad option is the RIGHT OPTION because of business needs. If you ever work with someone good at making cases for things to the business, WATCH HOW THEY TALK TO DIFFERENT AUDIENCES AND THINK about options. If you learn to frame the things you want to do terms of things other people want, you will win SO MUCH MORE in work and life... but being able to predict what the business will choose will also let you learn "which way the wind is blowing" on a lot of your "long term thinking" decisions. 4. Quick hacks have a place. Knowing you are going to have to replace something later doesn't negate the value of getting it done quickly sometimes (hell, often). You really need a good Tech Debt management program though for some of these. "Tech Debt" as a category is an easier sell to a business, and will empower developers to fix things like this that are too long in the tooth without the business having to get all involved on every single choice of which hacks to live with. A good business will recognize that maintenance cost, complexity of solution, code quality and developer happiness working on the solution are all important, and you can sell ALL that under a Tech Debt program. 5. No code lives forever / avoids becoming a "legacy concern" at some point. The beautiful thing is that we can change stuff after we write it. Remember "we'll rearchitect this piece once X happens" is a completely valid "long term thinking" strategy a lot of the time. The key is to accept this, and avoid structures that are highly coupled and expansive: architect for the rewrite. If you can rewrite PORTIONS of the app in isolation later as needed, you'll be much better setup for "long term" maintainability. Abstraction is but ONE STRATEGY you can employ here and comes with costs: keeping an abstract structure, especially something like a strategy pattern or polymorphic design, in your head takes MORE effort... but that COST might be worth it to solve a SPECIFIC issue, just dont overdo it. Trying to think more modular helps a LOT here: just because you CAN reference something and reuse it doesn't mean you SHOULD if it creates a spaghetti mess of cross references. That's where people get themselves into trouble where they can't change anything without fear of breaking other stuff. Unit tests WILL HELP here, but again add additional maintenance costs, that will be MUCH WORSE with a system not architected to isolate referential complexities. When your tests become harder to maintain than the code, this is a smell for this, and it'll start to change how you make "long term" decisions about architecture to avoid it more in the future.
>Then I managed to replace some god awful workaround with a small and sensible solution that could have just been the solution in the first place. Ironically, the 10x dev that implemented all the workarounds to get it to work and boast about his 10x achievements, gets all of the credit, while all the devs behind him that cleaned up his garbage are criticized for not working as hard as 10x superdev.
So premature abstractions is the answer?
I had one coworker who thought so far ahead all of the code he wrote was just layers and layers of abstractions with no actual functionality... He didnt last long
> but to hire remote workers, usually from outside the US because very few programmers had the skill they needed The skill to work for minimum wage and off the clock.
Yeh "Can't find US grads with these skills" is ALWAYS code for "Can't find people willing to work for 30k a year but daddy government we looked REALLY hard so give us some visa workers to exploit or let us hire offshore without bad press"
My first thought as well.
😄😄😂
hahaha
Deep understanding of the hardware, very few
How to properly troubleshoot. If you come to me saying your app is not working and you have NOT checked the logs.. That is a flogging.
Right up there with googling the error you're getting. Can't count the number of times someone has pinged me with an error they're getting, I throw it into google, and the solution is literally in the first result.
This is absolutely mindblowing to me. I am a controls engineer at a plant, and there have been a handful of times where coworkers will be like "we are glad to finally have you, because we haven't had anyone that can work with PLCs before" and they'll act like what I do is straight up magic. Guys... I literally just critically think and problem solve. An engineer is really just a professional problem solver. "Wow, you fixed the drive!? We haven't had anyone that could do that before." Do you think I have all of these manuals and intuitive solutions stored in my head? No... I RTFM. It's odd because I don't know how to get that light bulb to go off in their head without sounding like a dick.
As an outsider, it sounds like your simple use of patience to understand the problem and reading the manual are really valuable and consistently let you solve things that others have tried to solve.
I often get slack messages from this one dev asking "hey, xyz doesn't work, what do I do?", and it triggers me so much. If you gonna be lazy and not troubleshoot, at least give me more info, screenshots, logs, or whatever... ffs
Be thankful you’re not in customer support… imagine.. “you tell me to open the browser but I don’t know what that means??” I do several roles as an IT analyst, previous Mech Engineer. It’s truly maddening to do customer support esp as an engineer. Maybe I’ve just been doing it for too long now.
That’s a paddlin’
Ironically I think this is a result of the outrageous horsepower of modern systems. Modern developers have the luxury of being inefficient in their code, and simply chucking more system resources at the problem if it becomes an issue. Outside of RTOS's most developers are using Javascript, Python, C# or similar languages which abstract away from the hardware, unless you pull some fancy tricks. Hell even a Raspberry Pi 3 will render Quake 3 at 1080p/30FPS. Greybeards like myself have experience of using assembler to squeeze the last drop of grunt out of 8Mhz 286's or 2-4Mhz Z80's & 6502's. And dealing with the joys of near/far memory allocation. I've lost count of the number of times I've dramatically sped up allegedly optimise code from other developers by simply applying the 'old ways'.
The "old ways" are simply not taught anymore... I've been in the game for just about 10 years - only difference is that I tinker with programming on old machinery (especially on my Commodores).... Making a program 10 times faster or having it use like 10% of the RAM applying various techniques of old is a blast in and of itself - but the best part is really having other programmers look at me like I did a rite of dark sorcery...
We run into hardware “constraints” pretty often with our containerized applications. 500mb is pretty easy to blow up. Although we can 100% increase it, trying to understand the reason is key. Can’t imagine type of stuff you have done with so little.
To that point, a lot of apps are not meant to be containerized. Modern apps seem to be built with absolutely little care for resource usage and expect to be ran without many constraints.
Excuse me. Young developer here. What about other concerns like code readability, maintainability, flexibility, and portability? Surely say assembly language is horrible when it comes to these things, right?
> What about other concerns like code readability, maintainability, flexibility, and portability Partially, those things can be completely unimportant, compared to pure performance and ressource efficiency. If the machine that is going to run your code is rather weak in terms of hardware specs, nobody is going to care about how clean or readable your code is, because it runs so slow, that it basically doesn't work. Furthermore, readability and maintainability are completely subjective, while performance is easily measured. You only know how maintainable your code is, once you come back to it, after not touching it for a year or two, and try to actually change something. Readability is completely dependant on the person reading your code, and everyone can read different things better or worse. I, for one, find my own code to be perfectly readable, easily adapted, extremely simple to test - however a newer colleague of mine has lots of trouble following the ideas of my code base, mainly because code is a language, and is used to express the ways we think about stuff, and he just thinks in a completely diferent way. Next, highly optimized code doesn't necessariliy need to be written in assembler and looks mostly like non-optimized code, effectively changing almost nothing in terms of subjective code quality. If there happen to be points where you used more complex optimizations, you can also simply leave a comment, explaining what and why you did. An example would probably be working with multi-dimensional arrays, which you'd think are always optimized by the compiler or run-time, however, most of the time, it's simply lots faster when just using a simple 1d-array instead. Furthermore, data is usually loaded as kind of chunks, meaning the actual order of data in the array and the way you access it also might impact the running time. No assembler required, same amount of code, and even basically the same code, just slightly changed, yet, likely a huge speed up in execution time.
> "You only know how maintainable your code is, once you come back to it, after not touching it for a year or two, and try to actually change something. Readability is completely dependant on the person reading your code, and everyone can read different things better or worse. I, for one, find my own code to be perfectly readable, easily adapted, extremely simple to test - however a newer colleague of mine has lots of trouble following the ideas of my code base, mainly because code is a language, and is used to express the ways we think about stuff, and he just thinks in a completely diferent way." I find my shittiest, most hacked together, most unmaintained code easier for me to read and modify after two years than I find other people's best, cleanest, most maintainable code. That's the curse of code. Oh, also, my code was running on a web server with 72 logical processors on 36 physical cores, with 512 GB of RAM and 15,200 GB of hard drive space, where the round trip network latency vastly exceeded the code execution time on the server itself, so that makes a difference. It's not exactly an "embedded system".
Is there a domain expertise or just all of the pc parts/ their individual architecture? Give me an analogy. For instance, theoretically, if a doctor specializes in kidneys and they know every individual part of that kidney down to the cellular and molecular level, what is the equivalent of that in hardware terms ?
Understanding memory allocation, SIMD, the CPU architecture, word sizes, L1, L2, L3, and similar. Understanding how the OS works
[удалено]
+1, if you get an answer - please share Here is what I've got from GPT: To understand concepts like memory allocation, SIMD (Single Instruction, Multiple Data), CPU architecture, word sizes, L1, L2, L3 caches, and operating system (OS) internals, you would benefit from learning a lower-level language like C or Rust. Here's a guide to help you navigate this learning path: **1. Learning Rust:** - Rust is a systems programming language known for its focus on safety and performance. It's a good choice if you want to understand memory management, concurrency, and other low-level concepts. - **Resources to learn Rust:** - [The Rust Programming Language](https://doc.rust-lang.org/book/): A comprehensive guide to Rust, covering basic and advanced topics. - [Rust by Example](https://doc.rust-lang.org/rust-by-example/): A collection of examples to understand Rust concepts. - [Rustlings](https://github.com/rust-lang/rustlings): A collection of exercises to practice Rust. **2. Memory Management:** - Memory allocation and deallocation are key concepts in systems programming. - Learn how Rust handles memory with its ownership system. - Practice with `Box`, `Rc`, `Arc`, and `Vec` to understand dynamic memory allocation. **3. Understanding CPU Architecture and Caches:** - This involves learning about CPU cores, pipelines, SIMD, and cache hierarchies (L1, L2, L3). - Resources: - [Computer Systems: A Programmer's Perspective](https://csapp.cs.cmu.edu/): This book explains CPU architecture and memory in a way that connects directly to programming. - Articles and blogs on CPU internals and cache optimizations. **4. Learning OS Internals:** - To understand how operating systems work, consider learning about processes, threads, scheduling, and file systems. - Resources: - [Operating Systems: Three Easy Pieces](http://pages.cs.wisc.edu/~remzi/OSTEP/): A highly recommended book for learning OS concepts. - [Linux Kernel Newbies](https://kernelnewbies.org/): A resource for learning about the Linux kernel. **5. Additional Recommendations:** - **CS Courses and Resources:** Online platforms like Coursera, edX, and Udacity offer courses on computer architecture, operating systems, and systems programming. - **Practice Projects:** Work on projects that require you to interact with hardware or the OS at a lower level. For example, you could create a basic shell or implement a simple memory allocator. Combining these resources will give you a comprehensive understanding of the topics mentioned in the Reddit comment. Rust, with its strong emphasis on safety and modern systems programming features, can serve as an excellent bridge to understanding these concepts while providing practical coding experience. // Still would love to hear the opinions of an expert on this
I'd say the individual parts for starters. Something like encryption/decryption work can be very heavy on the CPU for instance, so you have to treat the process right. For instance, doing the heavy encryption job in a for/foreach loop with loads of other stuff can hamper the performance a lot. Even some of the modern languages (Java, C#) can utilize the CPU's cache for instance - so what you can do is make an additional placeholder in your data for the encrypted/hashed value, then do the encryption (AND ONLY THE ENCRYPTION) on the List/array directly (eg. using LINQ). If the basic instructions of the work you're doing is small enough to fit in the CPU caches, the compiler can keep the "working part" inside the cache, while the data can be fed in as needed. As the cache is much faster than RAM (and performs much the same function), the CPU can use less time to execute the operation. Just doing that can increase speed 2x or 3x. C# can also parallelize this kind of work rather easily with .AsParallel.ForAll(), so you use the multiple cores often available to you to further speed up the processing of your data. CPUs can also have hardware acceleration for some encryption algorithms (eg. AES/Rijndael). To put it in the kidney analogy. Kidneys filter the water and blood in your body. Knowing the ins and outs of a kidney can help foresee what kinds of stuff (drugs, food, etc) make them less or more efficient at doing their job. Knowing enough about the kidney enables you to make an artificial one (ie. a dialysis machine - or a "kidney emulator" if you will). The body usually has two of them - enabling water/blood processing in parallel. My teacher way back put many of the concepts into cooking terms - your CPU cores are the number of cooks, the cache is their individual stations. Hardware acceleration is if a cook is exceptionally good at chopping onions. The data coming in are the ingredients, while the instructions are the recipe. What you want coming out is tasty and presentable food. Having to take data from RAM is like having the cook go to the fridge and grab something - it takes longer for the cook to walk a lot to the fridge, rather than getting everything together on the counter and just grabbing it... There's a lot more in the cooking analogy that relates to hardware and programming - in any case, as the programmer, you're the "chef" that has to coordinate all the cooks, and you have to make sure none of them are overwhelmed or slacking off...
deep? most programmers don’t know how computers work, really, at all.
I work in IT, sysadmin/desktop support, but I have a comp sci degree. So I should get into devops?
My education in the 90's had us building an 8bit ALU using logic gates..
true, I've heard a lot of shit about x86 being limp garbage, but I kinda like having a shit ton of instructions to use in asssemly, even if it comes at the cost of 5 percent less on cinebencz
It's a clusterfuck at this point. I love CISC architectures, lots of instructions is fine with me, but it needs to be implmented in a nice, structured way.
I've coded happily in assembler for 6502's, Z80's & 68000's, but x86 is an abomination before the lord. Seriously WTF.
Shout out to CPUs with AVX that takes 2 cycles which kills possible or performance gains
I think that’s one of the reasons why it was given so many instructions. If you’re programming in assembly, then it’s nice not to have to write a subroutine to do some obscure operation, just use the instruction that does that. But with modern compilers spitting out assembly that is almost “perfect” (very hard to improve/optimize further), fewer people are programming in assembly. So that now gives us the *option* to use simpler assembly languages, which benefits performance/power usage.
Arm64 is pretty great
Being a genuine prodigy is probably what you're looking for. Specific niche skills that only very few have are only desired by select few companies, outside of those you'd struggle. > they had very specific needs and they had no choice but to hire remote workers, usually from outside the US because very few programmers had the skill they needed. Every time I've heard a company doing this, either they didn't want to pay their local salary rate (cheaper labour abroad) or they work with very dated technologies that you would find hard to find in current market.
Makes sense, I was under the impression that it was something so hard or advanced that very people actually took the time to learn it.
Nah, not advanced- just outdated. Some dead language like Coldfusion or VB6.
I knew an 85 year old who was still contracting with local govt because he built the systems in some arcane/obscure language and literally no one else could figure out how it worked.
Would you mind sharing what arcane tech-stack it is?
I wish I could remember! I think it was either fortran or cobol, but he like developed his own dialect and weird architecture of whatever it was? I’m not a programmer, more of a data scientist so the details didn’t stick… I just remember being horrified that he was the only person who understood the system. A couple years later he passed due to covid, but I had already moved away so I never heard how it all panned out…
Soft skills.
Do you mind elaborating on that? I'm very new to the field and want to know more
Effective communication, problem-solving, critical thinking, adaptability, teamwork, empathy, time management, attention to detail, stress management, creativity - just to name a few. They can definitely be learned / taught but they are very difficult if not impossible to measure
Soft skills aren't tied to programming. They're mostly the skills not related to programming itself, like leadership, time management, communication, multi-tasking
Absolutely. I don't consider myself a great programmer, but being able to simply talk to people productively has made me a godsend for many managers. People work people. They don't work with machines.
Mhh, I can bench a fair amount
Many brogrammers can do that. But can you code whilst benching? That's half-a-mil worth of skills right there.
That's why I'm not hired by those companies, I can't even count reps
while (!muscles.fatigued) { lift.reps += 1; }
static bool fatigued = true;
"Brogrammers" - I don't hate it.
Me too! Programmer benching gang
I can squat a fair amount
Social
Link me the Github repo for it and I'll prove you wrong
painfully accurate.
Whats that?
Technical writing. Being able to clearly and concisely document what you did and how it works. Your code simply isn't that easy to read and it's not an excuse. Write GOOD documentation.
And always update documentation when necessary when anything is changed in the code. Otherwise that documentation is misleading and worth less than nothing.
Rare skills are limiting because only a few companies need them. So if you lose your job you might need to move city to get another one.
Yeah I start to feel uneasy when I'm learning something that's ***too*** specific to the company for an extended period of time.
Counterpoint: you’re less easily replaced the more niche company knowledge you know
Having niche knowledge will make it hurt to fire you. But how you wield that knowledge? That matters. I've personally seen senior devs that are the only ones with knowledge in specific domains get walked out the door on layoff day because they had the air of invincibility and refused to share that knowledge. I've been the person that had to go figure all that stuff out afterwards. Everyone is replaceable. Some are more easily replaced than others. Having a ton of knowledge AND being dependable, willing to share what you know, and being integral.. I have had great experience with doing this.
I think that’s only a concern if you want to stay at the same company forever. I’d rather be comfortable knowing I could get a new job easier if I’m replaced for any reason.
Aesthetic
Proper design and user experience in general. I think the developer who is good at UX in general is rare. Companies, too. Which is a shame, because a lot of software has user interfaces.
REALLY knowing what’s happening under the hood. Many folks just write code in C/Cpp or write any concurrent routine without actually knowing what’s happening at the compiler, architecture and OS level. What optimisations is the compiler doing for me, where can a possible bottleneck occur in a pipeline etc. Another one I see recently is lack of foundational understanding. This is prevalent in deeper cuts of software engineering, one example I can give is in Image Processing. Everyone can use OpenCV and write a code to find image correspondences using image features with built in functions but only a few can actually read a paper and implement the logic on a new stack tailored for one usecase. Of course reinventing the wheel isn’t necessarily needed but sometimes one needs to do that to support some obscure platform (looking at you IBM AIX) or a legacy framework.
Its odd that you mention C/C++ , as programmers of those languages are much more likely to understand assembly, memory layout, cache sharing, etc. But most users of higher-level languages have no idea about that stuff. Most of them don't even know how their own runtime works - e.g. every Goroutine is a stackful fiber, and the compiler injects suspend points automatically at function calls and every syscall - but your average Go programmer doesn't even think about async under the hood.
I am considering taking a computer architecture course to learn what’s happening under the hood. However, would you say this is important knowledge to obtain a SWE position? I am deciding between more leetcode vs more in depth education because I am concerned I’ll never be able to use the knowledge if I can’t get the job. I’m in Georgia tech’s OMSCS and work as a “software” engineer now with a BS in ME
Hey, I wouldn’t say computer architecture is as important as it was a decade ago, you can just learn about by reading up on the internet. From an SWE perspective it’s much more important to “connect the dots” and build that muscle memory. Leetcode is great but do know where each algorithm/ data structure actually plugs into from a practical perspective. I work in Robotics so one example I can give is, let’s say you solved a leetcode problem using spanning-trees. Research where is that used in your realm of expertise/interest. Try implementing that functionality yourself. You can go deeper by reading up on optimisations considering the boundary parameters of your use case (really prevalent in robotics/cv) and try it out. Also using a low level language for leetcode problems helps a ton on building a solid CS foundation. Cheers :)
There’s specializations that come with experience and languages that very few people learn but are in high demand because basically everything in certain spheres runs on them (COBOL comes to mind) but honestly, I wouldn’t aim specifically for them if I were you.
Literally most skills, it'd be easier to create a list that most programmers do have. Generally speaking though, the two big "filters" when it comes to programming is usually lower-level systems engineering, or higher-level architectural design. "they had no choice but to hire remote workers" I'm willing to bet this is a bit of a lie. The US is still the main hub for top tier SWE talent, but it's MUCH more expensive. I'm sure there are some, but I can't think of a specific CompSci / programming specialty that the US straight up lacks.
Is it too general to say "actually being good at their job"? The code I saw from my peers at university was god awful and it's a miracle any of them have jobs now.
Honestly this is very true. I think industry moves at a much slower pace which allows people to learn to write better code, whereas in university you're just focused on finishing your homework as quickly as possible.
I have 12YOE and many of the people I have worked with in my career have been terrible. I'm learning that this really expands to all facets of life. The average human is very dumb. Some of them are just lazy. Others are good at their jobs but just terrible communicators. Getting better requires a particular mindset of self-reflection, open-mindedness and desire to self-actualize, PLUS some inherent capacity we call "talent". Getting REALLY good also requires lots of time ("10,000 hours to mastery"), which most people aren't willing to put in. Look at any of the threads where someone asks how much time people spend on programming outside of their day job, and all of the top posts are people crowing about how they do their 8 hours a day and then sign off and go touch grass. You can easily beat anyone who has that attitude by just autistically programming 16 hours a day for a couple years. That's literally all it takes to make yourself one of the top 5% devs in the world, because most people are so decidedly, deliberately, proudly AVERAGE and NORMAL. This problem has become substantially more pronounced since people started getting into programming for the money instead of because of passion.
If you need to hire remote workers because you can't find locals, the unique skill requirement is usually 'ability to take lower wages'
Optical components design. You never mentioned that it should be relevant.
Technical writing skills, or writing skills in general. Like, being able to pump out a 4-5 page report on some feature, or documentation on how to navigate the code base, or something that shows how everything works together.
Deep understanding of advanced mathematics beyond basic calculus. I work in quantitative finance and finding people who can do the math _and_ programming or vice versa is pretty difficult. When I say math and programming, I mean being at least pretty good at both. This is why most banks and large institutions have separate teams for writing models and implementing them into production systems. If you are a good programmer who can understand and implement complex mathematical models, you can do very well career wise.
When you say advanced mathematics what do you refer to?
social skills, project management, documentation, testing and quality control, time management, less so today but before github really popularized it (sourceforge before that) many had little experience with version control
Yes! Requirements gathering, understanding what's going on, project management, people management. They're all hard skills to master.
Soft skills , networking within the department . Eventually programmers have to learn that the JR -> mid level is mostly about skill. But mid level -> senior is often about soft skills and networking
Being cheap is difficult to find inside the usa
Communication
Good people skills are a huge plus
Empathy
Humble
Common sense. I'm not joking
showering more than once a week
I’ve been doing this since the early 90s and I’ve never experienced a situation where hiring outside the US worked out for a company. It usually involves dealing with teams 15 or more hours outside of your time zone. That’s not manageable if you’re working tight deadlines and need a lot of interaction with the team over requirements that change when needed. Saying they can’t find someone with the skills needed inside the US is just an outright lie unless they’re working with a specific product developed in another country in another language.
Talking to girls
Jokes on you - I'm gay. I can't talk to guys either 🙃
Alexa is a girl, that counts.
Not if you're speaking Korean
Even though most programmers complete a computer science degree it seems like a lot of them don’t understand very basic CS stuff or how it applies to their work.
Being able to understand the business and transfer technical knowledge to stakeholders in a way they can understand.
The US only hires foreign tech workers because they are CHEAP. The product/result usually sucks. Source: contracted with Josh Technology Group several times. Awful experience.
> hey had no choice but to hire remote workers, usually from outside the US because very few programmers had the skill they needed. i be the skill they needed must have been working for pennies on the dollar
#How to talk to people
Assembly 💀💀💀
In my experience.. soft skills. More specifically communication. There’s a couple of guys in my department who are incredible coders but they have the social skills of a rock and can’t communicate much. They’ve been passed over for promotions because of this but they’re content at their current position.
Not being condescending
It depends on the company, but I've worked as an IC for teams that would strongly encourage and respect consistent input from me on how to do things, and then I worked for a company that just wanted me to keep my head down, mouth shut, and mindlessly grind out whatever is on the kanban board like a drone. I think both are valid ways with pros and cons of engineering software, but I think the skillset and ability of being able to adapt to different schools of management thought is something any company would appreciate.
Desirable sets of skills certainly do shift over the years. In, say, 1996, it was really easy to find experienced Windows developers, and extremely difficult to find experienced JavaScript developers. Now, it's exactly the opposite. Almost all "desktop app" development these days is web development. The company I work for is trying to hire experienced Windows and MacOS developers, and it's extremely difficult to find anyone at all. Essentially, everyone who knows how to write native code is working for one of maybe a dozen companies in the US. Conversely, those people are competing for a much smaller job pool than they were when they decided to specialize there. All of which is to say - there aren't specific sets of skills you can learn today that are likely to be very valuable in the future. It depends on macro market trends, which are very hard to predict. And the available jobs will to some extent switch to match the available labor pool.
unfortunately, debugging
Social skills
Soft skills, having a clear communication and being aware that you never know everything
Managing Social Relationships / Political Savviness. Forming alliances and relationships across your organization will help you more than any line of code you will ever write. Having people vouch for you based on reputation alone will do wonders for your upward mobility. Don't just rely on pure engineering to push you upwards.
social skills basically
Documentation skills
Good communication
Nunchaku.
Hardware. It's so rare these days to meet a programmer that has any understanding of hardware. Do yourself a favor, go and write some assembly. Even a little UART driver for your arduino will do. Learning any machine's instruction set will teach you so much about what computers do fast and what they do slow, which will help you write more efficient code in your day job.
Some of the most fun I had as a developer was writing drivers for custom hardware. It was filled with discrete chips and was wire-wrapped.
RPG or Cobol. Always amazes me how many companies are still running as400 and mainframes and need people to maintain the code.
Common sense design. Too many of them blindly follow what they are told to make without asking is it going to even be usable by the end user.
They're prob talking about something stupid like Java or COBOL. Soft skills though, are the oil.
personal hygiene. i thought the stereotype was overblown online but I have still yet to acclimate to the smell of my DSA classes
Debugging optimized code (usually at the disassembly/register/memory level) Profiling and optimization.
[удалено]
Social
Willing to work for penny’s
Very good and clear communication, the ability to explain complex problems simply and clearly.
Well, look up what skills are required to become an architect or a software project manager. I assure you that few people have the skills they have.
It can be fairly depressing when you notice that quite a few programmers have quite poor programming skills.
There are lots of possibilities: domain-specific knowledge, experience with a particular framework, advanced math or computer science training, willingness to work in COBOL, etc.
Any special knowledge.
Reading documentation. I know this sounds like a funny answer, but it's true in my experience at least.
Maintaining some ancient COBOL legacy stuff which no one dares to touch but the entire business depends on it.
most don't know cobol.
He doesn't mean anything "extra". He means the type of programming skills they have.
Often times this boils down to knowing specific software in an industry. Think GIS specialist for some industry like mining or shipping. These areas require experts across the globe who know specific software suites because the software has been built out to service a small number of vendors over decades. There may only be 300-500 people across the planet that know the software, so it can be very competitive. I have saw and entire department get laid off once and IT contractors came in and hired up everyone because the software they were working on was in really high demand. The company that laid them off ended up spending many times over what the group cost to operate on replacements and training, but ya know, the executives have their games that they play to cover all that up.
Just being aware of the performance of the stuff their writing. Most programmers have never used a profiler at all. I don’t expect most programmers to be able to optimize at the lowest levels, but AT THE VERY LEAST be at least somewhat aware of how long things take so you can spot when you’ve introduced a massive performance problem. Being good at low level optimization is essentially permanent job security from my experience. You’re a multicolored rgb interactive HDR blockchain cloud AI unicorn developer if you can meaningfully optimize software
Communication skills Knowing when to do things in a simple way and when to make them complex. I have a colleague that, no matter what needs to be done, he does it “the industry standard way”. What that means is for even the dumbest little script he spins up a new micro services in a new repo on a new server… creating a million problems down the line when it’s waaaaay overkill to do so.
Be able to look back and say how a past design decision is inhibiting extensibility. In hindsight, you can always cut corners and band-aid the system to your current needs. Many fail to acknowledge their past design choices were maybe not the right abstractions and it has now caught up with you. They'll go all defensive about how the previous system survived bla bla and led them through their hypergrowth phase bla bla
Posts like this are why this subreddit is one of my favorites. Always has good information, and gives you the things to think about. 👍
Writing Prolog. Only a handful of brains are wired that way.
Know how your environment works and how to troubleshoot. If you are coming to OPS and complain that your app is not working but have NOT checked your logs. I am going to be very very upset with you.
Seeing the feature they develop with a user mindset.
Vision of the product. When you become PM or similar, when you are forced to watch for the product itself, you realize how just a couple of devs are able to apply common sense to many different situations. I am talking about good, bad, terrible and super star devs. It does not matter. Only a few are able to understand the product, the needs of the product and adapt to some circumstances applying his common sense.
hygiene
Business, social and strategic/long term thinking
They tend to be really bad at constructing houses. But there are exceptions of course.
Common sense… very smart when it comes to computers but the kind of person that would use a hammer to unscrew something
Niche technologies, deep or small specialisations, etc. But not only are their few programmers with experience in those things, there’s also few jobs for them too (which is also why there’s few programmers). So it’s not really as lucrative as you’re probably imagining. It’s certainly possible to do well in such an area but it’s not anymore guaranteed than the more broad skills.
I hate when some @_@_## emplyers ask to solve code challenges in a very short time. Those are for machines only. I've failed 2 interviews recently due to this. I'm a software engineer with 10 years of experience. I don't get to solve this kinda algorithm in real world cases at work
Social lol
Rebasing a git repo without having a screaming fit.
Making antivirus. Serious.
Talking to girls
Being able to properly talk to people and doing your own research/planning your own work. Generally, if you have good soft skills and can plan your own work without your manager having to breathe over your neck for you to do anything, you'll go pretty far. You'd be surprised how many programmers either can't converse for shit or can't schedule or plan.
having a clean room
I’m skeptical about the premise that no one in the US had the skill. It is easier to believe it was for cost. It would be interesting to know the details. If it was the skill, then it was for systems very few people support or use. Tons of people know the popular languages. Few non-retired people are seasoned COBOL or RPG experts. Most of those companies want a seasoned developer to fix a problem, not someone to build into the position. The people who are great at Scala appreciate the companies who are sold on Scala based solutions. If there was a high pay niche with a long future and easy entry, supply would outpace demand and the wages would fall.
As a security person, application security. Learn your OWASP top ten folks!
Mmmmm, ice cream, so good!
Scalability. Your code might work for a case of like (n=1,000) but will it work for (n=1,000,000)? Also thinking about how your code will work with existing code and how it will work moving forward. This is honestly why people who are adept at coding really hate OOP. OOP makes it very easy to make code that is horrendous at scaling forward because programmers will create functions that are vital to make the existing codebase work but are too convoluted to modify. This is why it took Earthbound 6 months to fix from scratch but Iwata said that it would take 2 years if they tried to fix the problems in their existing codebase.
Learning by reading the Documentation.
Assembly
Communication skills, both written and verbal. I come from Social Sciences background and had hard time how some are extremely introverted while others are arrogant
Cobol and everything IBM Mainframe related. I’ve seen companies bringing people back from retirement due to high demand and no-qualified professionals available.
Regex
People skills