4 ms·

This whole CRUD app crap is a cop-out - please don't insinuate it's my lack of experience that has me making this assertion. I've been an engineer for 23 years

This whole CRUD app crap is a cop-out - please don't insinuate it's my lack of experience that has me making this assertion. I've been an engineer for 23 years and spent the first 16 years largely working on large enterprise systems in C/C++, then C#, primarily in the health care space often with some hardware component. Regardless, the work I've done over the past 7 years with modern web tooling is some of the most difficult I've done in my career. It's a failure of the organization to not utilize entry levels from the first week. At any company. After all, the FAANGs of the world have a different bar of entry. People keep talking about this like you're literally training people how to program. That's BS. Every org has refactor work, tests to write, processes to improve, tasks to research, low hanging fruit bugs to tackle, systems to blueprint, all sorts of stuff that's a strain on the more sr. staff that's been pushed aside but needs to be addressed. You can strategically bring entry levels up in a way that's a net gain in any environment.

ebiester 8y ago
The truth, however, is that a senior developer is $140,000 and a junior developer is $80,000, and that same junior developer will be $100,000 in two years. (This is assuming salaries in one market.) That junior developer will take 3-4x the time to handle the same task as a senior engineer, and will take some of the senior engineer's time to guide the solution, provide feedback, and mentor. That doesn't mean that we shouldn't hire junior developers - in fact, it's our duty as an industry to hire and mentor. However, it is with open eyes knowing that junior developers are not cost efficient in many areas for the first year. But we go back to the original statement: "With all due respect, if hiring an entry level dev is a loss for your business then perhaps don't hire them? A dev should be a net gain regardless of skill level." If you have $320,000, and can have 3 junior developers or two senior developers with the same budget, the 3 junior developers will be a net loss for the first year. They can be productive, but you have to compare on budget. ___ But I find that as a bizarre set of work that you call out. * Refactor work is often the largest need from senior developers. Learning how to refactor safely is a separate skill that is not a skill junior developers have without instruction and feedback. * My senior developers write tests as they develop. If there is test debt, it means sitting down with a copy of Michael Feathers and that is definitely not an introductory text. Trying to write tests for code that wasn't written with unit tests in mind requires a set of skills that many senior developers don't have, much less junior developers. * I'm curious what processes you see that junior developers can improve. * Researching tasks can be something useful, but what are these tasks that aren't done while a senior developer needs a break? * Low hanging fruit bugs are likely the most obvious thing for junior developers, but a highly cohesive team that is writing tests has fewer bugs that are low hanging fruit. * What systems can a junior developer blueprint? A senior developer understands patterns and quickly solves the problem.
- brandall10 8y ago
  Pretty much all the things you call out as bizarre I've seen some better interns slice right though. * Refactor - Sitting down with a jr. dev for 15-30 minutes at a time going over the scope for something that is about a day or two of work. Done this many times. We're not talking high-level architecture work, just tech debt the team has let slip away. * Great. I've never been in a situation where there wasn't lack of coverage though. Focus on things that are somewhat repeatable in nature. The point is doing tests is a great way to learn how the system operates, and basic unit tests cornering edge cases are easily repeatable patterns. Validate w/ PRs, you don't need to hand hold the entire way. No books needed, tons of other tests in your suite serve as guidance. * Build/deploy system issues. 3rd party integrations. Better approaches to update dependencies. A better approach to documenting an API, automating code documentation, etc. Some particular lack that isn't crucial to operations but is fine letting a cheaper resource tackle as a research task. * Can blueprint anything that lacks proper documentation. If they can do research for their CS degree they can research and document your system. Yes, you will be giving them little tidbits along the way on how to properly debug or set things up. AFA 2 seniors vs. 3 juniors, totally dependent on your team structure and the work that needs to be done. If you run as tight a ship as you imply the sr. devs will be a better bet every time from a value basis - but that's rarely the real world. I wouldn't add more than 1 junior at a time to a team of < 6 devs. Lastly, addressing "that junior developer will take 3-4x the time to handle the same task as a senior engineer". Well duh, don't give juniors the same work as your seniors. The whole point of hiring lower level staff is you have work that is better suited for lower level staff, or rather, work that is too costly to give your sr. staff. This whole it's our duty to train the next generation... you're running a business, not a charity. And then you get caught up in this cancerous notion of people being in debt to you because you don't know how to properly utilize them.

ebiester 8y ago

The truth, however, is that a senior developer is $140,000 and a junior developer is $80,000, and that same junior developer will be $100,000 in two years. (This is assuming salaries in one market.) That junior developer will take 3-4x the time to handle the same task as a senior engineer, and will take some of the senior engineer's time to guide the solution, provide feedback, and mentor. That doesn't mean that we shouldn't hire junior developers - in fact, it's our duty as an industry to hire and mentor. However, it is with open eyes knowing that junior developers are not cost efficient in many areas for the first year. But we go back to the original statement: "With all due respect, if hiring an entry level dev is a loss for your business then perhaps don't hire them? A dev should be a net gain regardless of skill level." If you have $320,000, and can have 3 junior developers or two senior developers with the same budget, the 3 junior developers will be a net loss for the first year. They can be productive, but you have to compare on budget. ___ But I find that as a bizarre set of work that you call out. * Refactor work is often the largest need from senior developers. Learning how to refactor safely is a separate skill that is not a skill junior developers have without instruction and feedback. * My senior developers write tests as they develop. If there is test debt, it means sitting down with a copy of Michael Feathers and that is definitely not an introductory text. Trying to write tests for code that wasn't written with unit tests in mind requires a set of skills that many senior developers don't have, much less junior developers. * I'm curious what processes you see that junior developers can improve. * Researching tasks can be something useful, but what are these tasks that aren't done while a senior developer needs a break? * Low hanging fruit bugs are likely the most obvious thing for junior developers, but a highly cohesive team that is writing tests has fewer bugs that are low hanging fruit. * What systems can a junior developer blueprint? A senior developer understands patterns and quickly solves the problem.

brandall10 8y ago
Pretty much all the things you call out as bizarre I've seen some better interns slice right though. * Refactor - Sitting down with a jr. dev for 15-30 minutes at a time going over the scope for something that is about a day or two of work. Done this many times. We're not talking high-level architecture work, just tech debt the team has let slip away. * Great. I've never been in a situation where there wasn't lack of coverage though. Focus on things that are somewhat repeatable in nature. The point is doing tests is a great way to learn how the system operates, and basic unit tests cornering edge cases are easily repeatable patterns. Validate w/ PRs, you don't need to hand hold the entire way. No books needed, tons of other tests in your suite serve as guidance. * Build/deploy system issues. 3rd party integrations. Better approaches to update dependencies. A better approach to documenting an API, automating code documentation, etc. Some particular lack that isn't crucial to operations but is fine letting a cheaper resource tackle as a research task. * Can blueprint anything that lacks proper documentation. If they can do research for their CS degree they can research and document your system. Yes, you will be giving them little tidbits along the way on how to properly debug or set things up. AFA 2 seniors vs. 3 juniors, totally dependent on your team structure and the work that needs to be done. If you run as tight a ship as you imply the sr. devs will be a better bet every time from a value basis - but that's rarely the real world. I wouldn't add more than 1 junior at a time to a team of < 6 devs. Lastly, addressing "that junior developer will take 3-4x the time to handle the same task as a senior engineer". Well duh, don't give juniors the same work as your seniors. The whole point of hiring lower level staff is you have work that is better suited for lower level staff, or rather, work that is too costly to give your sr. staff. This whole it's our duty to train the next generation... you're running a business, not a charity. And then you get caught up in this cancerous notion of people being in debt to you because you don't know how to properly utilize them.