5 ms·

Take on challenging problems, ask lots of questions. Always try to understand both the technical decisions and business decisions/value in whatever project you’

by yashap 8y ago

Take on challenging problems, ask lots of questions. Always try to understand both the technical decisions and business decisions/value in whatever project you’re a part of. Try to avoid anything resembling blog/resume driven development - the real things to worry about are writing code that solves the business problem in a simple, quick way, while being easy to modify in the future, low on bugs, easy to monitor, and ideally reasonably performant. Using hot new frameworks/tech is unimportant, but writing well tested, modular code with the right data models, simple architecture, and good logging/telemetry/alerts is very important. Get comfortable with a set of tools that make sense for the work you’re doing - an editor/IDE, a debugger, a shell (and common Unix programs, if you’re in a Unix environment), a VCS, whatever build/deploy tooling your company uses, etc. Avoid the common dev mindset that dev managers, product managers and/or designers are the enemy. It IS your role to focus on important technical needs, but realize that they must be balanced against delivery times and business value. Sometimes you need to leave hacks in place, if there’s not too much cost to leaving them there. New features and bug fixes ARE often more important than cleaning up code/architecture, when you do take time for technical priorities, make sure you’re choosing high impact ones.

Aeolun 8y ago
I think you are needlessly dismissing resume driven development. While I agree that it is no good from a technical perspective, it’s really a fairly big part of what companies look at when they hire you (as I learned). Make sure it contains at least the latest fancy technologies in a professional context, and it will really help with your desirability. Then after you join the company, you can try improving their code to be up to standards.
- yashap 8y ago
  We might have a different definition of resume driven development. Choosing a company that uses a tech stack you think will be good for your career is fine, though it wouldn’t personally be one of my top criteria. But what I’m advising against is choosing frameworks, architectures, databases, etc. for a specific project, simply because they’re the hot new thing, vs. actually being the best choice for the problem you’re trying to solve, at the company where you’re solving it. Also, I personally don’t think the specific stacks you’ve had experience with play much of a role in getting top dev jobs. Getting great referals from senior people is generally the best way to get top dev jobs IMO, and you get these referrals by shipping reliable, high quality software consistently, and being pragmatic/mature.
  - Aeolun 8y ago
    Explain to me how I’m going to get referrals from the people I’m working for? If I ship reliable, high quality software, they have every incentive to keep me. I mean, old coworkers could potentially be a source of referrals, but not really.
    - yashap 8y ago
      I’ve found most high end hires work this way: - Person A and person B work together, both are fairly senior - Person B moves on to a new company. New company is hiring for a senior/lead/staff/director/whatever role. Person B says “we should recruit person A, I’ve worked with them before and they’re great” - Person A gets recruited for a great position, gets it as long as they do well in the interview On the flip side, I haven’t seen “experience with specific hot new tech” play much of a role in hiring for senior positions. I’ve conducted around 150 dev interviews, plenty of them for senior+ positions, and we’ve always taken the opinion “let’s just hire a smart, experienced, mature person, who knows what it takes to ship software, and knows how to balance technical priorities with business priorities. Ideally with a glowing referral from someone we trust.” We always assume that someone like this can learn our tech stack fairly quickly. Like at my current workplace we use a lot of Scala, MySQL, Redis, Kafka, K8s and gRPC, but would happily hire someone senior who’s used none of those technologies, but who has used similar enough ones, say Java, any relational db, any key value store, any queue/pub-sub system, VMs and REST.

by yashap 8y ago

Aeolun 8y ago

I think you are needlessly dismissing resume driven development. While I agree that it is no good from a technical perspective, it’s really a fairly big part of what companies look at when they hire you (as I learned). Make sure it contains at least the latest fancy technologies in a professional context, and it will really help with your desirability. Then after you join the company, you can try improving their code to be up to standards.

yashap 8y ago
We might have a different definition of resume driven development. Choosing a company that uses a tech stack you think will be good for your career is fine, though it wouldn’t personally be one of my top criteria. But what I’m advising against is choosing frameworks, architectures, databases, etc. for a specific project, simply because they’re the hot new thing, vs. actually being the best choice for the problem you’re trying to solve, at the company where you’re solving it. Also, I personally don’t think the specific stacks you’ve had experience with play much of a role in getting top dev jobs. Getting great referals from senior people is generally the best way to get top dev jobs IMO, and you get these referrals by shipping reliable, high quality software consistently, and being pragmatic/mature.
- Aeolun 8y ago
  Explain to me how I’m going to get referrals from the people I’m working for? If I ship reliable, high quality software, they have every incentive to keep me. I mean, old coworkers could potentially be a source of referrals, but not really.
  - yashap 8y ago
    I’ve found most high end hires work this way: - Person A and person B work together, both are fairly senior - Person B moves on to a new company. New company is hiring for a senior/lead/staff/director/whatever role. Person B says “we should recruit person A, I’ve worked with them before and they’re great” - Person A gets recruited for a great position, gets it as long as they do well in the interview On the flip side, I haven’t seen “experience with specific hot new tech” play much of a role in hiring for senior positions. I’ve conducted around 150 dev interviews, plenty of them for senior+ positions, and we’ve always taken the opinion “let’s just hire a smart, experienced, mature person, who knows what it takes to ship software, and knows how to balance technical priorities with business priorities. Ideally with a glowing referral from someone we trust.” We always assume that someone like this can learn our tech stack fairly quickly. Like at my current workplace we use a lot of Scala, MySQL, Redis, Kafka, K8s and gRPC, but would happily hire someone senior who’s used none of those technologies, but who has used similar enough ones, say Java, any relational db, any key value store, any queue/pub-sub system, VMs and REST.