What do software developers age 30 and over know now that they wish they had known in their 20s?

2023-05-16

Here are a few thoughts. I'd also recommend a thorough read of  Joe Wezorek's answer to this question . Life is long. Invest that time. Get more than one person's opinion.

Let me bat out a few based on my experience and observations. This list is not all-inclusive because it can't be. There will also be some overlap/redundancy/repeti tion (see what I did there) among items and I acknowledge that.
  1. Don't be afraid to learn on the job. Sadly, books at most workplaces are there on the bookshelves for marketing (look at what our hackers claim to read!) but you rarely see anyone reading one, especially not during core work hours. Still, you have a computer and can read papers and most books through an e-reader. So get to it. You're not going to learn much if you just do what you're assigned and little more. You also won't move forward if you ask for more work and get grunt work. Be willing to slow down and do things right and read up on the fundamentals. How dopeople develop an expertise in a coveted domain like machine learning? One day at a time.
  2. Manage your career aggressively. Take responsibility for your own education and progress. It's one out of 10 people (if that) who gets a "rabbi" or "mentor" who will clear paths and pull strings and make sure you come out on top for promotions and plum projects. If you're in that other 9, and you will be most of the time, no one's looking out for you. So look out for yourself. Don't ask for more work unless you trust that person to give you better work than you'd get otherwise. Do the bare minimum on stuff that's not advancing your career or teaching you something; if it has no career-adding value, people probably don't care enough about it for it to matter that you're putting in a minimum effort, as long as you don't get in anyone's way. After 3 years, if you're not being groomed for something bigger and badder, external promotion (read: changing jobs) is usually the way to go.
  3. Recognize underperformance and overperformance and avoid them. There are a lot of low-effort players who stay employed for years. This isn't a bad strategy if you're settled, but I wouldn't fall too low. That said, the only people who typically get fired for underperformance are the people who fail so badly that they generate work for others. People who hide and do little tend not to make any enemies. At the same time, be cautious of overperformance. This isn't like college where challenging your professor's ideas could earn you an 'A' if you argued your point well. Overperformers often also generate extra work for their superiors and colleagues and draw unwanted attention (see: McNulty in The Wire) and are more likely to be culled for "performance" (98 percent of "performance management" in companies is politics) than underperformers. I'm not saying that you shouldn't work hard and do a good job and learn as much as you can. That's not necessarily overperformance. In my experience, though, overperformance is much more dangerous than underperformance. It can get you just as fired and it will happen a lot faster. If you end up stuck between the two, prefer underperformance.
  4. Never ask for permission unless it would be reckless not to. Want to spend a week investigating something on your own initiative? Don't ask for permission. You won't get it. You're not actually doing your boss a favor when you ask for permission; from his perspective, you're asking for the right to pass the buck if your project doesn't pan out. Since he can deny you and your buck-passing after-the-fact, in any case, just because he outranks you... you don't really gain anything from such a promise you might extract in the first place. So there's no upside in asking for that permission. Of course, if you're going to do something that presents a real risk to the business or where his permission would be reasonably expected, then go ahead and ask for permission. If the loss is small and the risk is appropriate to your level in the company (and any programming job where you're not trusted with days to weeks of your own time is not worth having) then don't ask for permission. Just do it, and do it well. 
  5. Related to the above, never apologize for taking autonomy or the use of your own time. You can admit that a project or investigation didn't pan out, although it's best if you can spin it as a discovery exercise. Never, ever apologize for it. It sets a precedent of you as a subordinate whoneeds more supervision. After describing something you did of your own initiative, don't say to the boss, "Don't worry, I did it strictly as a weekend project." You sound like a fucking loser when you say that. If yourcompany won't let you work on something during normal work hours, then don't fucking do it on their behalf for any reason. Respect your time. Or no one else will.
  6. Learn CS666 (software politics) and you can (sometimes) forget about it. Refuse to learn it, and it'll be with you forever. As we get older, we tend to see the value in transferrable and general skills: functional programming rather than Spring/Hibernate; algorithms rather than quirks of a Java 1.4 legacy system. Well, CS666 ain't pretty, but it's transferrable across the industry in a way that no programming language ever will be. I'm not saying that one should become a political animal or get obsessed with the politics, because that won't end well, but one ought to be politically aware because there's politics in everything we do. It's good to start studying people and their moves early, even if you're not planning to play (and when you're young, you shouldn't play often). Whether you get the Hadoop cluster in time, who gets to make the technical decisions, whether you get that feature freeze you've been asking for so you can clear away some technical debt, and what projects you're assigned... all fucking politics, man. Meritocracy is the software engineer's Prince Charming and, in the real world you best be on the side that gets to define "merit" and structure how it is measured. If you learn CS666, you get some time to breathe and forget about it and just do great work. If you don't learn it, your career will be shaped by those who are better at it. 
  7. Don't be quixotic. Plenty of young engineers, when their ideas (which often are better than those of their superiors) find a lack of support, double down and throw in a lot of hours. "Let's prove our bosses wrong... by sacrificing our own time on something they will own!" Sorry, but if you have to throw down weekends (except on a rare occasion, like a production emergency) to bring a project through, that means that your bosses don't actually care that much about it. Otherwise, you'd have the time and resources and no patience for quixotry in yourself or others. Rather than trying to hit a home run with a cracked bat, you just should just let that game be. When bosses are "shown up" by people they doubted, they don't give that person an automatic promotion or raise. They find a way to confirm their negative impression (and your earnest self-association with a disliked project has put some stink on you) and, even if you succeed, you fail. If nothing else, there's always "He did a great job on that, but he was distracted from his assigned work and so I can't trust him going forward/we can't let him set a precedent/it was actually my idea."
  8. Don't fight other peoples' battles. As you're young, you don't have any real power in most cases. Your intelligence doesn't automatically give you credibility. If you get involved in someone else's fight, or stand up for someone unjustly treated, you'll just get mowed down. Watch Mad Menand The Wire and Breaking Bad for how people really are when there are any stakes. Save all your energy for your own fights. The corporate world is not a place where social justice is valued-- people protest by leaving, not picketing-- and you won't make any friends as a crusader. If you fight for yourself and it ends badly, you at least get some respect from some people (and that may pay off, years down the line) for your self-preservation. If you fight for other people, you're seen as an arrogant young fuck who didn't know the rules.
  9. Related to #8, try to avoid thinking in terms of "good" versus "bad". Be ready to play it either way. Young people, especially in technology, tend to fall into those traps-- of labeling something like a job or a company "good" or "bad" and thus reacting emotionally and suboptimally. "I'm not going to work hard because my boss yelled at Samtoday and I'm upset." "I'm going to sacrifice my own health and career goals and throw 90 hours per week after grunt work because this is a great startup and we're changing the world." "This founder will never sleaze me on equity because he's such a nice person." "I'd never work for a bankbecause some bankers do horrible things." Yeah, fuck that. Every organization is a mix of good and bad. Whatever the territory, use it to your advantage. Boss yells a lot? That actually makes him less of a threat to your career, should he go against you, because emotionally incontinent people aren't trusted by their own superiors. Assigned a boring project? It's probably boring to your managers too, which means they won't look at you much. You can put in a few hours per week and have 30-40+ left over to learn skills for your next job. Fucked-up culture? If you can stand it and others can't, you're a valued employee-- and can treat it as a learning opportunity ("MBA by counterexample.") It's important to stop thinking of every event as "good" or "bad" in some biblical sense and just see the angles and how to play it. This is a skill that seems to improve greatly with age. You stop sizing complex entities like corporations as "good" or "evil" and just learn how the play the landscape as it is.
  10. Never step back on the salary scale except to be a founder. As a corollary, if you step back, expect to be treated as a founder. A 10% drop is permissible if you're changing industries (out of finance and into biotech research) or moving to a lower cost-of-living area. Beyond that, the answer is "no" unless you're making a permanent move. Most people are actually really bad at assessing how good someone is at his or her job, which means that, in the private sector, your salary is the best assessment of your global rank and is a starting point for future negotiations. You better have a damn good reason if you step back, and it better be a high-status one. (If you drop back in salary for economic reasons, the answer is to trend-adjust your compensation. I'm not going to get into when to lie and when not to lie on a CV or in a job search because that's a fucking rat's nest of a topic and would double the length of this already-long answer.) Employee positions at startups are no exception (count the equity at zero, for the purpose of this item). If you leave a $150,000 per year hedge fund job for $90,000 "plus equity" (like, what? 0.05 percent?) then, congratulations, you're now a $90,000/year programmer. That's actually quite fine (being a $90k programmer) if you've moved to Idaho and intend to stay there, and it's fine if thecompany is arguably idealistic (e.g. clean energy) because you can probably bounce back to where you were if you're a good negotiator, but if you took that drop for a social media company, then you're just a fucking chump and, no, you're not changing the world by fixing bugs in ad servers.
  11. Exercise. It affects your health, your self-confidence, your sex life, your poise and your career. That hour of exercise pays itself off in increased productivity. If you find yourself no longer exercising, you're throwing down too many hours and you need to garbage-collect your life.
  12. Long hours: sometimes OK, usually harmful. The difference between 12% growth and 6% growth is meaningful. Applied to a $60,000 salary over 10 years, one takes you to $107,451 and the other takes you to $186,351. That's a big difference (not just in salary, but in the level of job that those numbers suggest). When your work is multiplicative in nature and your input/output relationship is truly exponential, work hard. Don'twork long hours on the merely additive stuff ("more of the same") that doesn't advance your career or knowledge in a long-standing way. If you're just doubling up on grunt work so some dickhead boss can save money because you're working 2 positions and taking 1 salary, then fuck it. Walk away. It may not feel like the case, but he needs you more than you need him.
  13. Recognize core technological trends apart from fluff. Half of the "NoSQL" databases and "big data" technologies that are hot buzzwords... won't be around in 15 years. On the other hand, a thorough workingknowledge of linear algebra (and a lack of fear with respect to the topic!) will always suit you well. There's a lot of nonsense in "data science" but there is some meat to it. Likewise, there's a lot of puffery and goofiness in "NoSQL" but non-relational databases do have their place. It's your job (and you get better at this over time, but start making guesses when you're young) to figure out what are core technological principles that make sense and are worth learning for the long term (e.g. functional programming) and which are just fads. It's still often useful to have fluency in the fads (for example, if you need a job right now) but you shouldn't spend too much time on them. Buzzword-compliant programmers with weak fundamentals get stuck writing glue code and having to learn new junk when their old junky knowledge goes out of style.
  14. Finally, learn as much as you can. It's hard. It takes work. This is probably redundant with some of the other points, but once you've learned enough politics to stay afloat, it's important to level up technically. And, when you're out of school and probably not going back, it's hard. Even the really smart people find it hard to read the cutting-edge papers. (In part, that's because many papers aren't well-written, but that's another topic.) No one is born with the ability to look at  (XTX)1XTy  and just intuit that it's the closed-form solution to least-squares linear regression (or vice versa). This stuff took the smartest people in the world hundreds of years to discover and, once discovered, it's much easier for the rest of us to follow along... but it's not without difficulty. If you want to be a great programmer, you'll probably have to study as an adult (with no grades!) harder than 95% of college students (and, maybe, 65% of graduate students) actually do study.
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

What do software developers age 30 and over know now that they wish they had known in their 20s? 的相关文章

随机推荐

  • Java实现快速排序算法

    原作者 xff1a 老铁123 出处 xff1a https blog csdn net qewgd article details 85949755 本文归作者 老铁123 和博客园共有 xff0c 欢迎转载 xff0c 但未经作者同意必
  • 手写ArrayBlockingQueue

    个人分类 xff1a 算法 编辑 原作者 xff1a 老铁123 出处 xff1a https blog csdn net qewgd article details 88363745 本文归作者 老铁123 和博客园共有 xff0c 欢迎
  • 手写LinkedBlockingQueue

    原作者 xff1a 老铁123 出处 xff1a https blog csdn net qewgd article details 88364742 本文归作者 老铁123 和博客园共有 xff0c 欢迎转载 xff0c 但未经作者同意必
  • Viewbinding自动生成XML的一个对应绑定类

    当你在项目 Module 的build gradle中的android 中设置 buildFeatures viewBinding true 设置完sync一下 xff0c 然后会在项目中看到对应的XML文件的一个继承了ViewBindin
  • AE制作Json动画教程

    本文将从为什么要做动画 xff0c 到动画实现方式 xff0c 再到用AE 43 Bodymovin制作动画 xff0c 结合实际案例行分享 xff0c 希望给新手带来一些启发 首先我们来聊聊 xff0c 我们为什么要做动效 xff1f 1
  • zabbix proxy 表分区

    zabbix server进行表分区的话 xff0c zabbix的内部管家会失效 xff0c 这个时候 xff0c 如果有proxy的话 xff0c 也要进行表分区 xff0c proxy表分区比较简单 xff0c 也不用每天更换分区 步
  • pycharm中unresolved reference怎么解决(配置问题)

    iunresolved reference怎么解决 解决方法 xff1a xff08 本人使用方法二解决的 xff09 方法1 进入PyCharm gt Settings gt Build Excution Deployment gt Co
  • ModuleNotFoundError: No module named ‘_ssl‘

    如果openssl是自己编译安装的 xff0c 安装python时需要注意以下问题 xff1a 从python官网下载的tar gz包或者tgz解压 xff1a 更改 xff1a Python 3 6 6 Modules Setup dis
  • Can I become a good programmer without math and algorithms knowledge?

    Knowledge of algorithms has very little to do with programming skill As some random dude on the internet once said 34 Wh
  • 线程进阶:生产者消费者模式和线程池

    一 生产者消费者模式 这是一种不属于GOF23的设计者模式 这种模式分为三个对象 xff1a 一个生产者 xff0c 一个消费者 xff0c 一个缓存区 生产者 某些程序 进程 线程负责生产数据就属于生产者 消费者 某些程序 进程 线程负责
  • Java异常

    目录 一 什么是异常 xff1f 二 什么是异常处理 三 Java中如何进行异常处理 1 try catah块捕获异常 xff0c 分为三种情况 2 多重catch块 3 finally块 4 声明异常 throws 5 抛出异常 thro
  • Linux系统安装mysql(rpm版)

    目录 Linux系统安装mysql xff08 rpm版 xff09 1 检测当前系统中是否安装MySQL数据库 2 将mysql安装包上传到Linux并解压 3 按照顺序安装rpm软件包 4 启动mysql 5 设置开机自启 6 查看已启
  • ffmpeg 花屏的问题

    ffmpeg 首先说明 xff0c ffmpeg并非做得毫无破绽 1 网络丢包 udp 改成tcp传输并非一定不会丢包 xff0c 这个一定要清楚 xff0c 除此之外 xff0c 如果使用udp xff0c 一定要把udp的接收缓存加得合
  • 通过使用 Byte Buddy,便捷地创建 Java Agent

    Java agent 是在另外一个 Java 应用 xff08 目标 应用 xff09 启动之前要执行的 Java 程序 xff0c 这样 agent 就有机会修改目标应用或者应用所运行的环境 在本文中 xff0c 我们将会从基础内容开始
  • Electron在windows下打linux包

    在原来打包windows包的配置的基础上做一些改动即可 参考我之前的博客 Vue cli 3 x使用electron打包配置 1 修改package json配置 xff0c 下面三个字段必填 xff0c 且author要按照下面格式填写
  • python3.7.1 提示 ModuleNotFoundError: No module named ‘_ssl‘ 模块问题 ;

    gt gt gt import ssl Traceback most recent call last File 34 lt stdin gt 34 line 1 in lt module gt File 34 usr local pyth
  • CentOS安装图形桌面GNOME

    CentOS安装图形桌面GNOME 购买了阿里云服务器 xff0c 是CentOS8系统 xff0c 一直只能通过终端命令来操作 xff0c 不太方便 xff0c 所以想要安装图形桌面 xff0c 试了两种方法 xff0c 这里记录一下尝试
  • SpringBoot启动机制(starter机制)核心原理详解

    一 前言 使用过springboot的同学应该已经知道 xff0c springboot通过默认配置了很多框架的使用方式帮我们大大简化了项目初始搭建以及开发过程 本文的目的就是一步步分析springboot的启动过程 xff0c 这次主要是
  • 解决前端做excel下载的文件打不开

    常用的excel对应得mine type类型 xff1a 1 34 application vnd ms excel 34 2 34 application vnd openxmlformats officedocument spreads
  • What do software developers age 30 and over know now that they wish they had known in their 20s?

    Here are a few thoughts I 39 d also recommend a thorough read of Joe Wezorek 39 s answer to this question Life is long I