4 ms·

Here's my world view. A junior engineer is proud he got his code to work, an experienced engineer is proud of the code he wrote to get the feature to work, and

• klodolph 10y ago
  All of the senior devs I know brag about how many lines of code they delete, if they brag about anything.
• liquidise 10y ago
  Agreed, but small critique: i hesitate telling more junior devs things that sound like "less code is better". It is a message that can easily be misunderstood as "if i write this in a more clever way the code gets shorter" instead of the intended lesson.
  • ferentchak 10y ago
    I always tell my team a good metric is "the least amount of brainpower it takes someone else to use to understand your code."
    • makr17 10y ago
      I've found that for me, "code so that I can comprehend it six months from now at 2:00am after several drinks" is a good motivator for "least brainpower".
  • metaphorm 10y ago
    I usually tell them this: "the only code you can be 100% certain has no bugs is no code".
    • patrickmay 10y ago
      "The fastest transaction is the one you don't execute."
  • deleted 10y ago
    [deleted]
• ben_jones 10y ago
  TIL I am half-way between experienced and senior!
• jameshart 10y ago
  A senior engineer is humble about the value her team delivered.
• sreque 10y ago
  I've seen some senior engineers take this too far. It's as if they are burnt out from all the code they shipped into production that broke things. They tend to favor solving problems operationally rather than through correct code. They also favor dumping problems onto third party libraries to the point of causing more problems than they would by allowing a more specific implementation. Some fallacies I've seen from senior engineers: "Let's ship the simpler solution even though it has clear problems. We'll hide it behind a feature flag and deploy it to a few machines first to make sure nothing disastrous happens." "Let's coerce a third party library to do the thing we want even though it wasn't really designed to do what we want. By using the third party library we don't have to take ownership of what we are writing! So much less code to maintain!" The second bullet in particular can be ironic because I've seen senior-engineer-written code break production because it tried to rely on a third party library to do something without doing any unit, functional, or performance testing to ensure it was doing the right thing and doing it fast enough. After having been in the software engineer for close to a decade, I see an increasingly worrying trend where companies just assume their engineers are incompetent and favor delegation to third party libraries, external services, and devops/metrics/monitoring to solve all problems. As someone who considers himself a competent engineer, I find the trend saddening because I'm not trusted to write correct code either.
  • angryasian 10y ago
    To answer your points from the perspective of a senior. 1. "Let's ship the simpler solution even though it has clear problems." You wouldn't believe how many times I've had to try to convince younger engineers that we don't need to over optimize and can't initially create the perfect solution because 9 times out of 10, the feature will change significantly, or get abandoned completely. Shipping the simpler solution is a way to test the waters and make sure you're building what is expected or wanted. 2. "Let's coerce a third party library to do the thing we want even though it wasn't really designed" Same point as #1. Whats the easiest way to get something out so that we can test and measure assumptions. Overall if you've read the article its about reducing risk. I don't want my team to spend 6 months on a feature to find out the feature is something that business or users want, nor do I want complete crap. The idea is where is the middle ground. Believe me I've dealt with many younger engineers like yourself that believe we should always roll our own solutions when its just not feasible. This is a clear distinction between a senior engineer and younger ones.
• foz 10y ago
  I think it's a myth that experienced engineers can write code that's more flexible and reusable. I've met plenty of experienced developers who believe they can architect a framework or library that everyone else can just build on. And they instead create big legacy software that breeds pain. I would counter that a senior engineer is proud of his team, who knows the best practices to ship stable, working solutions. And they are not afraid to throw code away when it ages, because they have the confidence and the team to quickly build something new, that's maintainable and reliable.
• ragix 10y ago
  My first job was working with my father, he is a very experienced automotive mechanic. Around 30 years at the time. He taught me the same idea. "If we have done our job well, you won't notice we have been there at all", the only difference is the vehicle will now function correctly. After 5 years working with dad I moved into my the field I had studied for and I've carried that advice with me over the years. So it's not just for coding.