R&D, software and embedded systems.
Small team, hugely collaborative by its nature and sometimes find ourselves faced with problems / puzzles with no apparent solution or precedent. Hugely rewarding when we can crack them.
I do genuinely feel for other respondents who seem to be bitter or cynical - despite the banter.
Ah, no concreted metrics for efficiency and delivery of results.
Explains why you prioritize employees who have fun on the job rather than efficient professionals who are there to do a job well done - you can’t really like to like compare with other teams (much less the broader industry) when it comes to delivering objectives because it’s all open ended and unique, so you really don’t know for sure which kind of employee is more effective but you do know for sure which kind is more fun to work with, hence you prioritize what you can measure - a fun team - not what is more effective and efficient.
Most work out there in software development is not “cracking interesting problems for fun without a strict timeline”, it’s “integrate new functionality into an existing massive custom-made system, which has at least 3 different styles of programming and software design because different people have worked on it over the last 8 years and only not a complete mess of spaghetti code if you’re lucky” - not really the kind of work were Enthusiasm lasts long, but it still has to be done and sometimes, millions, tens of millions and even hundreds of millions in yearly revenue of some company or other rides in doing that job well and in a timelly fashion.
Don’t take this badly, but from where I’m standing you’re in the playground sandbox of software engineering. No doubt it’s fun and even an environment others would love to be able to work in, it’s just not the place for professionals and doesn’t really reflect most of the software development being done out there, so not exactly a representative environment for determining what kind of professionals are suitable for the wider industry.
A lot of what you’re saying is spot on and I respect your experience in this and the other comment.
I don’t hire for fun though. I hire for a diversity of perspectives, integrity and authenticity. We teach people how to constructively challenge and go after problems or objectives that may have no off the shelf solution (if they do, we may acquire it).
The problems are usually P&L quantified and prioritised before they get to us - we only have to do that legwork if it’s something we’ve generated.
It does feel like a playground to a degree and I do love the work - perhaps yes it’s less ‘professional’ and structured. We do have experienced devs and architects who I would hope aren’t reproducing problems - but it’s often our job to find a technical solution (if appropriate) to a problem, not to ‘productionise’ it or maintain it. This involves a handoff to others in the business and they ultimately determine how it is rolled out.
I get that this isn’t typical of the market and thanks for your response / take on this. One thing we have to be careful of is being ‘institutionalised’ and that will come across as naive, perhaps it is, but that has been a help.
Sounds to me like you’re doing the fun part of the job - “solving challenging problems” - without having to do the vast majority of the work (which is seldom as much fun), such as making it suitable for actual end users, integration with existing systems and/or migration, maintaining it during its entire life-cycle, supporting it (which for devs generally means 3rd level support) and so on.
So not exactly a typical environment from which to derive general conclusions about what are the best characteristics for a professional in software engineering in general.
Mind you, I don’t disagree that if what you’re doing is basically skunworks, you want enthusiastic people who aren’t frozen into a certain set of habits and technologies: try shit out to see if it works kind of people rather than the kind that asks themselves “how do I make this maintainable and safe to extend for the innevitable extra requirements in the future”.
Having been on both sides of the fence, in my experience the software that comes from such skunkworks teams tends to be horribly designed, not suitable for production and often requires a total rewrite and similarly looking back at when I had that spirit, the software I made was shit for anything beyond the immediacy of “solving the problem at hand”.
(Personally when I had to hire mid-level and above devs, one of my criteria was if they had already been through the full life cycle for a project of theirs - having to maintain and support your own work really is the only way to undrestand and even burn into one’s brain the point and importance of otherwise “unexplained” good practices in software development and design).
Mind you, I can get your problem with people who indeed are just jobsworths - I’ve had to deal with my share of people who should’ve chosen a different professional occupation - but you might often confuse the demands and concerns of people from the production side as “covering their asses bullshit” when they’re in fact just the product of them working on short, mid and long term perspectives in terms of the software life-cycle and in a broader context hence caring about things like extensability, maintenability and systems integration, whilst your team’s concerns end up pretty much at the point were you’re delivering stuff that “works, now, in laboratory conditions”. Certainly, I’ve seen this dynamic of misunderstandings between “exploratory” and “production” teams, especially the skunkworks team because they tend to be younger people who never did anything else, whilst the production team (if they’re any good) is much more likely to have at least a few people who, when they were junior, did the same kind of work as the skunkworks guys.
Then again, sometimes it really is “jobsworths who should never have gone into software development” covering their asses and minimizing their own hassle.
I’m curious.
What’s your line of work, if you don’t mind?
R&D, software and embedded systems. Small team, hugely collaborative by its nature and sometimes find ourselves faced with problems / puzzles with no apparent solution or precedent. Hugely rewarding when we can crack them.
I do genuinely feel for other respondents who seem to be bitter or cynical - despite the banter.
Ah, no concreted metrics for efficiency and delivery of results.
Explains why you prioritize employees who have fun on the job rather than efficient professionals who are there to do a job well done - you can’t really like to like compare with other teams (much less the broader industry) when it comes to delivering objectives because it’s all open ended and unique, so you really don’t know for sure which kind of employee is more effective but you do know for sure which kind is more fun to work with, hence you prioritize what you can measure - a fun team - not what is more effective and efficient.
Most work out there in software development is not “cracking interesting problems for fun without a strict timeline”, it’s “integrate new functionality into an existing massive custom-made system, which has at least 3 different styles of programming and software design because different people have worked on it over the last 8 years and only not a complete mess of spaghetti code if you’re lucky” - not really the kind of work were Enthusiasm lasts long, but it still has to be done and sometimes, millions, tens of millions and even hundreds of millions in yearly revenue of some company or other rides in doing that job well and in a timelly fashion.
Don’t take this badly, but from where I’m standing you’re in the playground sandbox of software engineering. No doubt it’s fun and even an environment others would love to be able to work in, it’s just not the place for professionals and doesn’t really reflect most of the software development being done out there, so not exactly a representative environment for determining what kind of professionals are suitable for the wider industry.
A lot of what you’re saying is spot on and I respect your experience in this and the other comment.
I don’t hire for fun though. I hire for a diversity of perspectives, integrity and authenticity. We teach people how to constructively challenge and go after problems or objectives that may have no off the shelf solution (if they do, we may acquire it).
The problems are usually P&L quantified and prioritised before they get to us - we only have to do that legwork if it’s something we’ve generated.
It does feel like a playground to a degree and I do love the work - perhaps yes it’s less ‘professional’ and structured. We do have experienced devs and architects who I would hope aren’t reproducing problems - but it’s often our job to find a technical solution (if appropriate) to a problem, not to ‘productionise’ it or maintain it. This involves a handoff to others in the business and they ultimately determine how it is rolled out.
I get that this isn’t typical of the market and thanks for your response / take on this. One thing we have to be careful of is being ‘institutionalised’ and that will come across as naive, perhaps it is, but that has been a help.
Sounds to me like you’re doing the fun part of the job - “solving challenging problems” - without having to do the vast majority of the work (which is seldom as much fun), such as making it suitable for actual end users, integration with existing systems and/or migration, maintaining it during its entire life-cycle, supporting it (which for devs generally means 3rd level support) and so on.
So not exactly a typical environment from which to derive general conclusions about what are the best characteristics for a professional in software engineering in general.
Mind you, I don’t disagree that if what you’re doing is basically skunworks, you want enthusiastic people who aren’t frozen into a certain set of habits and technologies: try shit out to see if it works kind of people rather than the kind that asks themselves “how do I make this maintainable and safe to extend for the innevitable extra requirements in the future”.
Having been on both sides of the fence, in my experience the software that comes from such skunkworks teams tends to be horribly designed, not suitable for production and often requires a total rewrite and similarly looking back at when I had that spirit, the software I made was shit for anything beyond the immediacy of “solving the problem at hand”.
(Personally when I had to hire mid-level and above devs, one of my criteria was if they had already been through the full life cycle for a project of theirs - having to maintain and support your own work really is the only way to undrestand and even burn into one’s brain the point and importance of otherwise “unexplained” good practices in software development and design).
Mind you, I can get your problem with people who indeed are just jobsworths - I’ve had to deal with my share of people who should’ve chosen a different professional occupation - but you might often confuse the demands and concerns of people from the production side as “covering their asses bullshit” when they’re in fact just the product of them working on short, mid and long term perspectives in terms of the software life-cycle and in a broader context hence caring about things like extensability, maintenability and systems integration, whilst your team’s concerns end up pretty much at the point were you’re delivering stuff that “works, now, in laboratory conditions”. Certainly, I’ve seen this dynamic of misunderstandings between “exploratory” and “production” teams, especially the skunkworks team because they tend to be younger people who never did anything else, whilst the production team (if they’re any good) is much more likely to have at least a few people who, when they were junior, did the same kind of work as the skunkworks guys.
Then again, sometimes it really is “jobsworths who should never have gone into software development” covering their asses and minimizing their own hassle.