4 ms·

I'm going to over simplify this, but I really have noticed two types of developers that I have worked with and/or managed. There are engineers who favor the sci

by lcw 10y ago

I'm going to over simplify this, but I really have noticed two types of developers that I have worked with and/or managed. There are engineers who favor the science, engineering and technology aspects of what we do. They tend to love learning new algorithms, building libraries that do complex things or just simply trying a new programming language as opposed to building a video game or the next popular app. Then there are the developers that see the code and job more as a tool to build something and enjoy the process of completing a project more then the technologies used to do it. They tend to build video games or fun apps. Both obviously like technology, and have to dabble in both sides of this simplified equation, but they favor one over the other. I find that the engineers that like the science, engineering, and tech side of programming are the people predisposed to over engineering. On the other hand I find the people who enjoy finishing projects predisposed to not making something extensible enough. I really think there is a good mix of both of these types of programmers in every dev environment of any size.

xsmasher 10y ago
That "extensible enough" is a good phrase to remember; part of the job is figuring our what parts of the problem are likely to change in the future, and what parts are likely to stay the same, and exposing them accordingly. This can depend highly on the problem space; as a game developer, I can consider "number of seconds in a day" to be a fixed value that will never change never. In other fields, that assumption could get your fired.
- ViliusVilius 10y ago
  >"number of seconds in a day" That's where you're wrong, kiddo.
nicholas73 10y ago
Which type do you think would make a better developer / employee? I'm firmly in the second camp. I'm intellectually interested in the things listed for the former, but for thought process only and not cranking out code for it. For me, the nuts and bolts is work, while brainstorming and refining the product is the fun stuff. I don't work as a software engineer, but I worry if I did it would mean more of the former and less of the latter.
- lcw 10y ago
  I think it really matters what you are hiring for. If you are working on a tough technical problem like a machine learning algorithm around fraud and you have some runway I would always pick the former. If you have tighter timelines and a more well defined technical problem say a new social media app then I would always pick the latter. However, if you can hire two developers, and they both are equally intelligent I would pick one of each to build a team to complete the examples above. When you have two people that respect each other and fall on each side of this scale they can be an incredibly effective team. For instance the former will push the latter to be better at writing code. I see this play out a lot in code reviews. The latter generally will finish more tickets or features than the former, and it will help the former not get caught up in technical details because they don't want to put an unfair burden on their counterpart. This makes the former better at efficiently building programs. They can really balance each other out well and what you can get out of it is a project that finishes on time with a solid foundation. That said I have seen this backfire too, but this is mostly when they don't like or respect each other. What can happen here is the former will say the latter is a terrible programmer, because their code is garbage and is not extensible or naive. Then the latter comes in and says the former doesn't finish anything they get caught up in the details and their production is horrible.... so hiring open minded intelligent human beings is important. Personally I favor finishing projects because I like building things, and I have built a career for myself that I am happy with. My previous comments are once again over simplified, and they were really just a break down of engineers that are predisposed to over engineering. Employers actually don't force you to favor one side or the other in my experience. They want to play to your strengths and what you want out of your career. So if you are a person who likes finishing projects and you are good at it then they will quickly put you in a role where you lead business projects from the engineering perspective. If you favor the science, tech, and engineering side they will put you in a architect or platform role that pushes the underlying technology choices for the business moving forward. Find a good company and go for it if you like programming and building things. I did it and I really enjoy what I do.

by lcw 10y ago

xsmasher 10y ago

That "extensible enough" is a good phrase to remember; part of the job is figuring our what parts of the problem are likely to change in the future, and what parts are likely to stay the same, and exposing them accordingly. This can depend highly on the problem space; as a game developer, I can consider "number of seconds in a day" to be a fixed value that will never change never. In other fields, that assumption could get your fired.

ViliusVilius 10y ago
>"number of seconds in a day" That's where you're wrong, kiddo.

nicholas73 10y ago

Which type do you think would make a better developer / employee? I'm firmly in the second camp. I'm intellectually interested in the things listed for the former, but for thought process only and not cranking out code for it. For me, the nuts and bolts is work, while brainstorming and refining the product is the fun stuff. I don't work as a software engineer, but I worry if I did it would mean more of the former and less of the latter.

lcw 10y ago
I think it really matters what you are hiring for. If you are working on a tough technical problem like a machine learning algorithm around fraud and you have some runway I would always pick the former. If you have tighter timelines and a more well defined technical problem say a new social media app then I would always pick the latter. However, if you can hire two developers, and they both are equally intelligent I would pick one of each to build a team to complete the examples above. When you have two people that respect each other and fall on each side of this scale they can be an incredibly effective team. For instance the former will push the latter to be better at writing code. I see this play out a lot in code reviews. The latter generally will finish more tickets or features than the former, and it will help the former not get caught up in technical details because they don't want to put an unfair burden on their counterpart. This makes the former better at efficiently building programs. They can really balance each other out well and what you can get out of it is a project that finishes on time with a solid foundation. That said I have seen this backfire too, but this is mostly when they don't like or respect each other. What can happen here is the former will say the latter is a terrible programmer, because their code is garbage and is not extensible or naive. Then the latter comes in and says the former doesn't finish anything they get caught up in the details and their production is horrible.... so hiring open minded intelligent human beings is important. Personally I favor finishing projects because I like building things, and I have built a career for myself that I am happy with. My previous comments are once again over simplified, and they were really just a break down of engineers that are predisposed to over engineering. Employers actually don't force you to favor one side or the other in my experience. They want to play to your strengths and what you want out of your career. So if you are a person who likes finishing projects and you are good at it then they will quickly put you in a role where you lead business projects from the engineering perspective. If you favor the science, tech, and engineering side they will put you in a architect or platform role that pushes the underlying technology choices for the business moving forward. Find a good company and go for it if you like programming and building things. I did it and I really enjoy what I do.