flamboyantkoala

joined 1 year ago
[–] flamboyantkoala@programming.dev 1 points 10 months ago

This seems like it’ll be a really long journey without labeled data. Do you have an idea of how much fraud is in your sample set?

[–] flamboyantkoala@programming.dev 8 points 10 months ago
  1. Once I felt like I had mastered a language I’d start learning another. The techniques in a new language would teach me things to take back to my primary language. Functional Programming for instance was great at teaching the value of simple functions. Prior to that I’d put everything in Objects which had implicit state leading to sometimes hard to reason about code. Also Objects still have a place for making easy to reason about code.

  2. If I saw a new technology I thought would be useful I’d try it on my own before trying to incorporate at work.

  3. Downtime at work was used to learn more programming by working on projects that would help make my life easier at work. Bash scripts, improved builds, improved developer tooling

  4. In the corporate world. Learn the soft skills, when to talk when to be quiet. How to brag about your work appropriatly to get those raises.

  5. Constant learning. Programming changes fast. If I stuck to what I started with my skills would be far out of date and my job selections would be slim.

[–] flamboyantkoala@programming.dev 1 points 11 months ago

Coming back to code after a year is hard regardless of language. I’ve had C code I came back to after a year that was dead simple language feature wise but hard as hell to follow business wise. I would actually argue more modern features like Union types in typescript has actually made it easier for me. “Oh this function has to handle two cases of objects an object with an id and without an id”

[–] flamboyantkoala@programming.dev 9 points 11 months ago

I’ll have to disagree with this. Adding new features is a problem if old things break but otherwise it just makes future programs easier to write.

You should be writing your next set of code with the newest features if they cut down dev time, cut down bugs or make that area more maintainable

I was a fast track developer. Was senior in 4 years but involved a few job hops. Many companies require x years to get to senior but for some reason that goes out the window for new hires with talent.

It wasn’t until managing people that it became obvious why I fast tracked and others don’t. There is a huge difference in our industry. I like to use the analogy of sports. You have multiple levels recreational, college, and professional. As you get better you move up but there’s a gate to moving up that some never achieve maybe genetics maybe effort. The difference is it’s all mixed up in programming there’s no divisions you can have a 15 year programmer stuck at rec level and he’s programming with a 3 year college level athlete that’s running absolute circles around him. The productivity gap is huge. If you manage to get a pro level programmer on your team he’ll make the other 3 rec level programmers look like a waste of money. It’s like the elite runners who complete a marathon in around 2 and a half hours and it’ll be another 4 to 6 hours before the slowest finish. That same gap is in the programming world it’s just not as obvious.

So all that said my advice is to find what your skill is. If you seem to be outperforming your elder peers you’ll benefit from aggressively asking for raises and promotions as well as making a job hop every few years if HR stagnates your pay for the dreaded “years of experience” excuse.

You might also eventually get promoted to a point where you find yourself not excelling. This was my experience in management. I became a manager too young or maybe I’m not built for it. After a few years hating management I went back to programming as a consultant because I realized I was on that upper side of the skill differential, I enjoyed coding and now armed with that knowledge of where I am I can ask for even higher amounts of pay exceeding management pay.

[–] flamboyantkoala@programming.dev 89 points 1 year ago (7 children)

You don’t triple your software output by going to the office. You can improve it by getting developers uninterrupted time with a healthy line of workable items ahead of them.

This is probably going to have the opposite effect they desire.

Agile in it’s current implementation with excessive meetings wastes more time than the mistakes it tries to avoid.

I guess it’s all in the interpretation because I heard it as the government spending money to keep the fat fat. Paying for their fudge rounds instead of either a) putting them to work or b) restricting them to a healthier diet.