You need Software Developers to believe in your project (2020)
iism.org
iism.org
However for every project I take on, there will always be something I have never done before, or a maybe some new technique I want to try, could be a new language. That's where the engagement comes from.
I don't care about the project, I care about writing code (and exploring writing code) to the best of my ability (and to the best of the project constraints).
If I've done my job well, that means I learned something new/had fun and the project will never burn my screen pixels ever again.
In the same way, when you hire a contractor build you a garage, you look for someone who will use their experience to build a good garage with the best materials and techniques keeping in mind the priorities of the owner, like maintainance, cost, appearance, resalability, etc. You don't want someone showing up who just views your garage primarily as an opportunity to learn about this new construction material they've heard about that doesn't help you.
I'm hiring them because they're the expert - and if they ask some questions about why I want the garage and what I plan to use it for, it'll help them deliver a final product that's a better fit for my needs.
For example, if I say "I want a garage that's 200 square feet and has an epoxy-covered floor", I'd like it if my contractor asked me some questions and came back with responses like "Since you want to do x in your garage, I'd avoid the epoxy floor and go with painted concrete. Also, I've has several clients who were interested in doing x and they ended up wanting a storage loft in the garage. You can add one later if you'd like, but it's much less expensive if you add it during initial construction."
So...maybe not passionate, exactly. But engaged and professional, absolutely.
I'm asking because I see the construction analogy pop up a lot and I just can't reconcile the two things.
To me the development of a new blueprint for a new kind of garage for a new kind of vehicle operated by a never before seen alien species is a bit closer to creating a software product.
I mean, who would ask a contractor to do what people regularly ask software engineering teams to do?
A desire to learn is not a desire to experiment.
> In the same way, when you hire a contractor build you a garage, you look for someone who will use their experience to build a good garage with the best materials and techniques keeping in mind the priorities of the owner, like maintainance, cost, appearance, resalability, etc.
Meatspace contractors try new techniques all the time. You're paying for the ability to accommodate a client, not the ability to do the exact same thing repeatedly.
> You don't want someone showing up who just views your garage primarily as an opportunity to learn about this new construction material they've heard about that doesn't help you.
That's a terrible analogy. Most of the time developers aren't writing greenfield projects, meaning they don't choose the stack. Devs have the leverage to choose by accepting jobs that use the stack we know (or want to know).
As to contractors, if you had already started building a garage with a new construction material, you probably would really want to hire people who were experienced in it. If you couldn't find them, you might want people who were interested in learning to use it.
If you want passion and motivation, consider hiring an actor or prostitute. I'm going to stick with my usual plan of "write good code in exchange for good money".
It is like med school interviews. Everyone knows the answer to "why do you want to be a doctor?" is "I like science and want to help people." along with an anecdote proving that when tons go to medicine as it is a well paid and stable career.
From my own experience I find that yeah, job interview answers are mostly self-marketing BS. But I do also care about the quality of the end product beyond just having fun with the tech.
I would not encourage anyone to talk to their boss the way GP is talking. But these are peers talking, and if you don’t think convos like this happen, then you haven’t seen them or you’ve dismissed them. If you haven’t seen them, I can only assume nobody trusts you enough to vent.
Most businesses that pay salary operate like this:
Worker picks 5000 apples, coworkers picks 300. Business pays them each 1 apple. Both start picking 1 apple, business puts them on improvement plan. (China wants apple pickers to struggle.) Also, please write a 13-page paper detailing how your soul is mine, I'm your daddy, and any food you might try to grow on your own property is actually mine (Google).
Hard disagree. There is a place for the developer as product evangelist, and there's a place for the developer as a skilled tradesperson.
The idea that someone needs to be fully invested in your worldview to pipe together a backend is... strange.
There’s a fine line between having to cajole a bunch of disaffected developers into getting work done, and explaining that I can’t give you a raise because it would ruin the company and you really should think about what’s best for the team. Or could you just work late on Friday, or cancel your honeymoon.
What you're suggesting is just hustle culture nonsense. If you want someone to be invested in your company, give them _equity_. If you won't (and you won't), accept that you're paying for a transactional relationship, not "investment".
I come from a family of contractors (electricians and metalworkers mostly), and every experience I've ever had working with them tell me that they care about understanding. If you ask them to make you a bathroom without any waterproofing they'll ask you if you've gone mad and tell you that you NEED waterproofing, because they understand that you don't want your house to rot. If you say you want a metal frame and you have a drawing. The very first step they will take is to analyze your drawing to see if it makes any sense.
I have never worked with a contractor that just did whatever you told them to, without understanding what you're doing. If they chose to disengage with a problem, it's a conscious choice.
The big differentiator is the ease of understanding. Building a bathroom is relatable. You kinds of intuitively understand why you want a new bathroom, and people understand the sorts of issues a new bathroom can solve. People do NOT understand what new software can solve, and how it solves it. They think software is magic pixie dust that you sprinkle on problems to make them go away. That means we have to do more of the work of helping them map out the solution than a contractor would.
Nowhere did I suggest otherwise.
> I've ever had working with them tell me that they care about understanding.
They care about understanding to complete the task at hand. I have never met a contractor that got emotionally invested in whether the cabinets you picked out were the cabinets of your dreams. I've met many contractors that were, in some ways, invested in the buyer being satisfied with their job, but that's not really the same thing.
> I don't care about the project, I care about writing code
this is like the contractor saying they only care about installing cabinets, not helping you model your bathroom.
The point is that you want someone that's going to look at the plan and say "that's going to rot in 2 years", not just do the exact thing requested by the customer and leave
This depends on who you hire. I recently built a home and dealt with lots of different contractors with different attitudes. Very often when they needed clarification they would come to me, and very often I would ask them "what would you do if it were your home?".
I worked with companies and workers who I would hire again in a heartbeat - they understood what I wanted from my home and how it would be used. They incorporated this into designs and decisions made on site (because I don't care how well you think you've planned, there are ALWAYS decisions to make one site).
The people I would never work with again were the ones who either never even asked for clarification and simply chose the easiest / cheapest solution to a problem (often surprising me - in a bad way) or when I asked them what they would do in their own home were not interested in engaging with that question - they would respond by asking me again what I wanted.
You may not care if your current employer considers you a bad hire or not, and that's fine. In our industry, in this market, you can get away with that. Some of us hold ourselves to a higher standard.
This is just silly. Your argument is that you would care if your employer developed ridiculous and contrived metrics and then assessed your value based on them? I don't really think your holier-than-thou statement makes much sense in that capacity.
As I said, equity drives investment. If you don't own a percentage of the success, you're trading time for money. This is neither new nor controversial. Any suggestions otherwise are, again, hustle culture propaganda.
> Your argument is that you would care if your employer developed ridiculous and contrived metrics and then assessed your value based on them?
No. As I alluded to, I think that a developer who does not care about his or her end user is a worse developer in concrete ways.
Remove developer and answer again.
??
You're just....saying things...? What does "Caring about the end user" have to do with "Believing in your product"?
I've seen this in software too. People push for cheaper and faster, but often that will only come at the cost of quality. There are good reasons to take on technical debt. For example, to get to market without the funds to avoid technical debt, in the hope you can pay down that debt with revenue flowing in. But there are seldom conversations with business people to negotiate on the quality, time, and cost trade-offs.
EDIT: just be clear I'm still actually talking about software
Too little of the former, and nothing valuable gets done. Too little of the latter, and you end up drowning in technical debt, preventing the business from adapting as quickly as it needs to
If you want your workers to care about the success of your business, then pay them with the success of business (e.g. shares). If you are only paying an hourly salary, you're not entitled to anything but their hour's output.
Being now on the donating end of shares, employees know much better how to value the gross pay.
While adding in new technologies isn't always a bad thing, having nothing but a desire to do so is classical Resume-Driven-Development. If your firm is in a business position such that having all the latest, greatest tools is a good thing (hard to imagine industries in which this is an unqualified good) then keep on trucking. Otherwise you may find yourself needing to have adult conversations with $RDD_DEV about just what it is that makes the business money, in light of technical decisions that cost additional time, have larger TCO, and so on.
What I see too much are teammates who say they want to be more involved with customers or prioritization but don’t show up for feedback sessions or high level discussions and then later complain about not being involved enough, causing even more headache. The more you accommodate, the more problems they come up with, and never actually get around to doing the actual work.
Then one of them suggested that we install a bay window instead of the boring thing we'd had planned, and when it costed out reasonably, they got right on it. The tools came out, the enthusiasm was turned on, and a couple of them spent half a day building an absolutely beautiful window that I and our pets value to this day.
Good workers doing stupid, boring jobs are likely a resource that companies are not taking advantage of. People are more capable, and sometimes you should let the reigns loose (maybe most of the time).
The reason developers love to work on personal projects is not primarily because it is using some shiny new tech but because they own the vision, they own the decisions, they started the question and they want to build the answer.
I was able to automate this for them with a pretty simple VB.net script. Several days of boring mind-numbing work per month were reduced to a couple button clicks and a few seconds of CPU time. It also eliminated all typographical errors on the part of the printing company.
I never touched vb.net again after that. I had no interest in the technology at all and there was nothing particularly interesting about the work itself. However saving people from having to do a bunch of boring work is extremely satisfying. And it saved the owner money which feels great too.
I find that being empathic towards my users not only makes the work more fulfilling but it also allows me to design better products. As a human with human interests you should at least give it a try.
I think that for me, being a good engineer is first and foremost about solving problems for people, and if I lose sight of that simple goal, I lose a lot of my energy for my work.
The problem solving process never ceases to amaze me, how a problem can go unsolved for months on end, and then suddenly all the dots can be connected and the solution appears.
Starting out with the notion that "It must be possible to solve this", is always the first step i find.
I would say it can be tempting if you fall into one of the two broad buckets to think the other side is doing something wrong and that there is a tendency to want to compel them to “see the light” so to speak but in my experience those efforts tend to go to waste (if not appearing outright condescending).
Ultimately people have different interests and priorities both in life and their careers and people derive fulfillment from different sources. There are no right answers here.
[1] https://www.michellelim.org/writing/stop-using-frontend-back...
How is it hard to have empathy and interest in solving problems and yet still a deep love and interest in the underlying tech you use?
I feel I am in this category. I would venture to guess that a broad array of useful developers do as well.
Siloing people like this creates an artificial construct wherein people feel they need to fit.
For what it's worth, I would definitely not hire the OP after his speech about being more interested in using a new tech to solve my problems than solving my problems.
My technology-focus projects are unlimited and therefore never satisfied.
I think what makes the difference is the proximity to the user. In your printing company you got to know the process then build a solution that directly helped your co-worker and boss. Even if it only helps in a small way that feels very satisfying. Where I get frustrated is and lose all that empathy is when the company keeps multiple layers of indirection between the devs and the users (customer report -> Customer Service -> Product Management -> devs).
Have you seen Bumblebee? I don't know what your idea of a "decent" Transformers movie is, but if you still like the original series there's a lot to like about Bumblebee, including character designs, voices, and dialogue that are close to the 1980s originals.
I’ve seen this many times, participated a couple. In the end there’s a moment you should move on to something more interesting. And like selling your house, you should never look back at what they did to your code.
For developers, the process of delivering value IS the excitement, it doesn't matter how awesome or boring the product itself is, it's the process of writing good code to solve customer problems that excites us.
So you do care. But you care about the technology, not the InCrEdIbLe ImPaCt this latest "X-but-as-an-app" is going to have on the course of human history.
There's nothing wrong with you, and I'd love to work with you.
Don't get me wrong, I have gotten pretty decent at making crud apps, but I find it so much more compelling if the crud app is making education more efficient, vs another problem that I don't care about.
I just find it so foreign that software engineering culture holds your mentality more often than not, where the tools that you are working with are advertised more than the problem you are solving. Not good nor bad, just an observation.
This type of mechanical reasoning is a common pitfall. People did too much symbolic reasoning they end up embracing too much symbolism instead of real life and real people.
If you can't find something that you care about to work on, why do it? Isn't it worth everything to do something that you're proud of with your life?
It's not mutually exclusive.
Do you think tax attorneys are proud of tax laws, or do you think they care about being the best tax attorney in their field? This mind set isn't exclusive to certain industries.
As a developer working on business-related tasks your net contribution might even be negative with this attitude (because if you don't understand the business and you are not even interested in understanding it then the only tasks you can do yourself must be so small and so well specified that it (the specification) might take more time than doing the task itself).
Many of who use the argument "Apple/Google does it this way" I'm not saying your now right it's just been my experience that they aren't engineers or Computer Scientists.
The problem is that they often don't know the constraints of the system you're working with, something that only comes with actually working on the implementation.
E.g. I was working on a display. The graphics were designed by a UX Team. However the display only had 256 colors, had to be readable outside, had a 320x240 resolution. They had designed everything as vector graphics with highest color settings on really good Eizo monitors. The customer thought the designs look cool, and I wasn't given any freedom in improving them.
I tried discussing the constraints with them, but because they were "on top" they wouldn't listen.
In the end the customer saw the prototype and said it looked terrible. But I had all the communication with the UX Team and them that I wasn't allowed to make it work for this display.
In the end it cost everyone an extra month and a lot of frustration to arrive at basically what I suggested when I first checked the hardware.
The problem isn't to learn about UX, it's that you have a "UX person" that may not know about UX and dictates the terms.
If one's priority is design freedom or whatever, a good working relationship with your higher ups is the best chance to enable that.
Working well with managers is also a good strat for becoming one yourself, and having more influence over things you care about.
True, the problem is more when companies become more and more top-heavy over time. These intermediate layers are created. With every layer it becomes less likely that the people that can actually decide won't ever hear valuable feedback until it's too late.
>Working well with managers is also a good strat for becoming one yourself, and having more influence over things you care about.
In the end I showed them what had to be done to make it look decent on this kind of display. Because all layers of management were in the room, they managed to decide to do these changes. It's just a very inefficient way to get to this point.
People not listening come in all forms. UX, dev, MBA.
Unless you have valid reason to think the user would prefer your way, this sounds like the correct chain of command for a strong product.
Repeat the above for as long as you want.
Of course, the kind of place the GGP is complaining bout won't let peasants like developers to take part on that phase, so win-win, I guess.
It’s like that guy that said: “it’s easy to be a good investor in god times, it’s when recession hits that the pros really shine”
No true Scotsman would ignore the technical specs!
The fact is that many UX designers are designers first and foremost and maybe even entirely non-technical when it comes to specs. The existence of "true professional" UX designers does not mitigate the vast quantities of average skill UX people most teams will encounter.
I don't think that's much of an excuse. A graphic designer needs to know about page bleed and colour spaces. A product designer needs to understand the strengths (literally sometimes) and weaknesses of the materials they are working with. And a UX designer for a tech product needs to understand the technical constraints of the medium they designing for, or be able to talk proficiently to someone who does.
How can you design a user's experience (lest we forget what UX stands for) if you don't understand to at least some level the medium through which it will be conveyed. Designing something that a user will never see because the colour depth of the display they be using can't convey it is not designing the user's experience at all.
Right. Most designers are not UX designers, they are graphic designers hired to do UX because they can make pretty pictures in Illustrator.
A UI is essentially the highest layer of abstraction we build and thus should follow the same principles as any other. Namely respecting both the lower and the upper abstraction barriers.
UX designers are responsible for the language on top of all these layers. They need to understand the human side of things (often through data or through direct interaction such as workshops), but also the technical and artistic side of UI implementation. Direct interaction, written documentation and learning are paramount.
The good thing is that we programmers also want to understand the layer above us, so there is a natural pull for programmers and designers to communicate and to refine that communication.
Everything else was out of my hands.
Who said you did?
UX person suggests a design that is sprinkled with choices that clearly are from someone that has not been on the web that long, like wrong icons.
We do a meeting and explain what is going on, what the user wants to see on the page, and the UX comes back (usually that same day - how quick of them) with another version, but this version shows that the UX person did not understand the problem again. And again. And again.
I've seen the UX person showing a wireframe to the user and asking 'Will this cover all scenarios?'. Client said yes, we delivered the feature monday, and tuesday client was 'hummm, without the hability to do scenario X, this won't be used'.
The reason the UX person is so beloved between a bunch of devs is only because of the UI aspect of it - it looks good, something we devs could not come up with. But damn, I would love to work with an UX that I feel that knows what she's doing.
In fact I've seen several engineers trying to migrate to UX but the gatekeeping and prejudice made them give up.
I find "graphic designers" to be enormously helpful in solving problems related to user interaction and judgment with regard to use of color, typeface, and effective use of limited screen real-estate.
There are good ones and bad ones. The key is to assess where they are, and learn how to communicate with them with regards to any technical impacts.
The last thing I'd want to do in collaborating with a team-mate is summarily judge them as "my inferior". But that's (unfortunately) just me.
most organizations that tend to have office politics and are very politically-correct in their behaviour tends to end up with people in roles calling shots, despite those shots not being great.
graphics designers is just one example of this that i've seen, where a poor UI or bad UX is mocked up, but because you're an engineer, you do not get to have much input or your input is regarded as irrelevant (because your role is to code, not do UX design).
That's what i mean by the "inferior" comment - that the UX/UI designer isn't as good at their craft as you are in implementing code.
UX people, UI designers and PO/PMs who see developers purely as interface xerox machines don't really deserve much respect.
1) I've never met a UX person who is a programmer. Most of them are from graphic design background, sometimes for vouchers or magazines and they don't necessarily understand that the computer screen is not the same kind of medium as a piece of paper.
2) Having a professional relationship entails pushing back and questioning. Being a "yes man" to the UX people is not a good working relationship. The implication of your comment is in order to push back and provide feedback I must first acknowledge my subservience to their whims and only once they approve of my work I may humbly submit some suggestions for their kind consideration.
It often seems like there is more verification of that than whether it does what was intended.
"Here's a mockup - we spent a lot of time on this".
"OK... what does it look like on tablet, mobile, what are the failure states, what should error handling look like?"
"We spent a lot of time on this - make it look like the mockup".
Had a project years ago that was... almost as bad as that sounds.
The problem of course is that it's too easy to focus on pixel perfection at the cost of other things.
Recently, I've worked on a project and we had to force ourselves to 'not care' about those things until the very end when we did clean up.
Thanks for noticing — I hope to be on a project of yours soon.
I don't think this means open source desktop programs are a great place to look for top-notch UI/UX inspiration.
Electron is basically the digital equivalent of coal-rolling in my opinion, technologies like React Native are a much more elegant way of achieving what Electron tries to.
You're setting a really low bar there. If you compare open source UX to the UX of closed source applications pre-iphone, you'll find that their incomprehensibility was frequently criticized. Case in point: GIMP.
What's changed is that closed source UX has gotten worse faster than open source UX (unless you count GNOME, which has set world records for how fast it degraded).
You apt-get install it, you double click on your photo, you use a pretty standard WIMP interface to edit it.
Compared to modern Adobe software that's fucking amazing.
Hell, even Paint.NET has a better interface than GIMP.
And that is just one thing, the whole program is littered with small obnoxious design decisions like that. Maybe you can learn to get used to it after a while, but if you have to go through a tutorial and get lost the first 20 times you try to draw a basic shape then your drawing program has bad UX. In the end you will learn that the ellipse button and rectangle button are the same things etc, but until you learn all those things the program is just frustrating to use.
And then the rectangle button changing to an ellipse button just because that was the most recent sub tool you used is a UX issue that is purely in the UI. I probably lost several hours to that until I understood what happened, because I couldn't find the buttons I wanted to click on and then assumed I had to look for them elsewhere etc. And it still is bad even after I learned that since everywhere I look at tutorials how to do stuff the menu looks different since they had different previously active tools so it is a pain trying to figure out what to click.
You're right about the tool menus, those are an actual UI issue, but they can be disabled. Maybe they should be disabled by default? I can't say.
Now, it would take some work to implement those quick buttons, sure, but that is purely an UX change it doesn't add any new capabilities to the program, it just makes some actions easier to do.
Basically, the feature lacking in the program are those "quick buttons" which would make adding these simple UX fixes easy rather than burdensome engineering work.
Anyway, you might be right about this issue, I am not an expert on image editing. However I do understand UX and your view on development will lead to horrible UX like what you have in Gimp. It might work great in enterprise products where you sell features and not UX, but a product intended to be used by normal users needs more work on UX for people to like them.
Just to make it a little clearer what I mean here: if there were actual shape drawing capabilities on the backend then it would be pretty easy to make any kind of circle/ellipse tool that you wanted, or set up the circle tool to do what you want by default, but those don't exist right now.
That isn't what UX is about. I am making games, and stuff that isn't simply moving things about is a core part of user experience. For example consider a game where you want to move around armies on a map. You can implement that by moving around the armies using numpad only, or you can calculate a shortest path on a mouse click to a location and show it to the user. Both allows the same kind of movement, but the second offers way better user experience which is why all modern big strategy games uses it over one step at a time movement.
> but my point is you can't just get that by changing around the ellipse select tool
I never said that a good UX was easy, I just said that the developers of GIMP didn't want to put into the work to make GIMP have good UX, and a lot of that work is redesigning the technical architecture or implementing those features the tedious ugly way. It is possible to make it decently easy to make easy to use tools for gimp, I just don't know all the details of what those tools should do exactly but I know how to build that sort of things. When making games you don't have as patient users as you have in GIMP, so you'd never get away with that kind of UX, so from my perspective when your product has GIMP's level of UX then it isn't complete as a product since it would basically ensure business failure.
>the developers of GIMP didn't want to put into the work to make GIMP have good UX
From what I have heard from GIMP developers, this is not correct. There is plenty of desire to fix issues, the main issue is lack of contributors. Please help if that's what you're interested in.
You're talking about "getting away with the UX" but I'm also not sure what you're talking about there, GIMP is not a commercial product that is trying to get customers. It's an open source project driven by volunteers who improve it in their free time because they feel like it.
Zxzax is correct that GIMP is an alternative to Photoshop, so the tool pallet is appropriate for editing photos. The typical workflow is: (1) stack layers, (2) mask layers, (4) composite. It’s rare to draw a circle on top of a photo. Usually it’s most efficient to select an area of a photo with a rectangle to isolate it on a layer, then use masking to refine the non-rectangular edge. If your goal is to draw a 2D illustration & work with gradient meshes, then Inkscape is an alternative to Illustrator. Both those programs are for illustrating in 2D and there are purpose-built features for drawing & editing shapes.
That said, GIMP does have real UX issues. For example, the controls and GUI elements don’t scale well to high resolution screens and could be much better on tablets like the Surface. They’re also missing CMYK color space support. But, I always assume they’re waiting for Adobe patents to expire to add those features.
CMYK support is not a UX issue, that is another thing that's missing on the backend. I don't think it has anything to do with patents, the problem is more because of lack of manpower.
>small developer led teams often refuse to bother to even consider that they have to change anything to fix these things.
The GIMP developers are aware of this pitfall and want to avoid it, there is even a FAQ entry about it: https://www.gimp.org/docs/userfaq.html#i-dont-like-gimps-use...
This is not the same thing as bad UX.
Nearly every time design becomes political and every change needs to be conformant to even the most minute standards even if they may not have any material effects on the product. I think the field just has a lot of shitty “leaders”, most of the “grunts” I’ve worked with have been incredibly helpful and willing to think out of the box to make UX easier.
"Is this component really that shitty for the user?" is how you end up with...hell, insert any Enterprise software here.
In well functioning product teams everyone should be working together to make a better product, recognising the roles and strengths of each other. If this isn't the case, then your org has bigger problems.
That's rarely the top priority for everyone on the team at the same time. Design folks want to 'design', and agreeing that 'feature X' doesn't need to be in the screens - even if it's "the better product", doesn't align with their career need to have showcase material for the next job interview.
Similar with tech/dev folks - an update feature might just need simple poll mechanism, but that doesn't give them experience with building a full pub/sub scalable architecture platform, or testing out the newest messaging libraries.
The more people on that team, the more conflicting priorities there will be.
This doesn't sound like a great team, and doesn't really align with my (sure, admittedly limited) experience. I've only really worked once with someone who had strongly personally motivations that worked against the teams goal, and it was recognised that they were a wanker.
That is completely true. To work together to build a product, to have everybody understanding what is what needs to be achieved, and collaboration in general is the way to go.
In organizations where business does not trust engineering, engineering does not trust design ... things are never going to work. It is a collaborative effort, one point of view is insufficient to create an attractive product in a cost-effective way that is not full of tech-debt.
I also find that backend people tend to have extremely good ideas when it comes to UX (better, even, than a lot of UX people), they just don't enjoy or aren't good at executing these ideas (or aren't allowed to). The takeaway is to take your backend engineers' opinions seriously and let them touch the frontend when they want to.
At the point we have a functional prototype, go through it with UX so they can understand all of the pieces before they do the design. Sometimes it leads to minor improvements on what the engineers already came up with. Other times it leads to an overhaul.
But as long as all of the core functionality is built first, iterating on the design will just be moving a few things around.
I long for the days of building a simple site for my company. No fancy wizards, bifurcating flow, or complex animations. I unfortunately don’t think we’re going back to that time though.
E.g. this job add was on my feed right now: https://jobs.ashbyhq.com/moderntreasury/dc9bcfe8-64ef-4377-a...
While you may be able to build a working page, can you ensure that every engineer builds it with the same interactions, flows, language, and even colors? Will you build and test it for the users the UX team has researched, or will you build it for yourself?
I can keep consistentancy by just having a JS library that has our components.
As for flow no I can't because different situations and objectives require different workflows to force them all to be the same is the kind of thing that sounds like a good idea until it is clearly not.
But the funny thing about all of that is that everything listed above has to be done either way, and usually the UX guys will shove it off on engineering to implement so where is their value add....?
My first startup made an application that tried to control changes to projects and stop scope creep, and this reminds me why I thought there was a market for it. :)
What I do find frustrating is when they only concern themselves "happy path", and developers don't have the authority to fill in the gaps. It creates a waterfall-like experience where you are often stuck waiting to hear back from product/design to make a decision because they didn't consider a scenario where the user might submit a form with an incorrect field or some other seemingly obvious path.
Another bad practice is product people who assume screenshots or Figma files are technical requirements; not realizing these only give you clues as to how something will look, not how something will work, so flows and business logic go under-examined by product, which can lead to more "let's hold off on that, let me think about it" after telling you to start something ASAP.
IMHO, loading states and error states are one of the more important parts of the design since they'll be seen often (for loading) and when the product isn't working for a user (error states).
I don't need believers. I need professionals instead, that will do their best during the working hours, and implement things as requested, even if they personally think the project itself is totally nonsensical.
However, what I would expect from developers is to be professionals and strive to the high technical quality of implementation, even if they don't believe in the usefulness of the project.
EDIT: Looks like I was not clear about my role. I am not some business owner messing up with the technical decisions and asking developers to "be professionals" and "do what they are asked".
Instead, by "being a professional" I am arguing that we as a technical team need to focus on the technical implementation of the business request, even if we don't believe in the business value. We can tell business if something doesn't make sense to us, but in the end it's their responsibility. We should not push our view of business requirements upon them, as much as we don't want that business push their view of technical implementation to us.
The other is one that I find poorly considered and a waste of money and effort. I try to do both to the best of my ability, but for the second project it has been made clear to me that my opinion is not really appreciated and that my technical opinion is not valued this has hence killed my initiative and desire to go above and beyond or my desire to advocate for changes for the betterment of the project. Not because I am lazy or resentful I've just learned that attempting to do so on this project is a waste of time and effort and my energy would be better spent elsewhere.
However, as an internal technical team full of professionals, we are making sure that right technical decisions are taken during the implementation, and we don't allow inferior SAP tools that "work out of the box with the SAP ERP" to pollute our technical landscape, and we are not letting SAP consultants to further lock us in into their world.
That's the part where we still can be professionals and do a great implementation of a "shitty" project we don't believe in. But you are right, if we were not allowed to be professionals and if business would not respect our technical decisions, it would not be our fault to be demotivated and just do the bare minimum required not to be fired on the spot.
Even worse, of course, are 'passionate' developers. They're a real nuisance.
How often have you seen starry-eyed people like this push their pet technology into a project just because it was their passion, but without any view as to the wider technical context or business context. They can be a real menace. Not because they aren't technically competent. But because their judgement is poor. Looked at from a distance, they aren't looking at what's best for the company or the project, but what's best for themselves.
Orthogonal is a great word. Don't weaken it.
Projects with excellent communication that are not in the least compelling.
For tractable, straightforward, or routine software development, this seems very true. For middling-difficulty, this seems often true.
It's more just the edge cases - problems requiring a lot of creative thought or unique problem-solving tactics - where it seems like getting software developers to "believe" would be a huge boon.
Just as curiosity is a large multiplier to learning, genuine interest is a large multiplier on difficult mental work.
As a side note, offering "interesting" and "meaningful" work can be seen as another perk of a job listing (just like other optional benefits), especially to young or idealistic devs.
And these are very reasonable requirements.
As programmer, what I want from leadership is product vision, basic knowledge of software quality economics, lack of scope creep, technical debt control, good people management, and respecting the law. More often than not, you get zero out of these six.
These are all great things to ask for. I'd also be tempted to add "Ethical decision making and respect for the end user's time, attention, and privacy" but now we're moving into crazy-land.
In my experience, intellectual honesty has greatly limited my career.
I physically can't outright lie. But over time I've gotten (minutely) better at diplomacy.
- Rephrase negatives as positives. eg Instead of "Don't run!" ask "Please walk.'
- To always sound encouraging, supportive. h/t Guy Kawaski's depiction of Gassée in The Macintosh Way. "Wow, what a great idea! You've clearly put a lot of effort into this." https://en.wikipedia.org/wiki/The_Macintosh_Way
- Compliment sandwiches, surrounding criticisms with praise. Gene Wilder's letter to the costume designers for Willy Wonka is an oft cited example.
- All that active listening and empathy stuff. eg Really, really listening to people, instead of just waiting for my turn to talk. eg #2, in meetings, hold back with my own feedback to see if any one else will make the same points first, thereby not sucking up all the oxygen.
Etc.
It's fucking exhausting. But like all skills, it does get easier over time. And my (probably wrong) perception is that I'm slightly less boorish and offensive.
PS- I save up all my unsolicited feedback energy for HN. Haha.
You'll be senior executive VP of advanced design actualization in no time!
Fast track!
More seriously, I discovered two weird unexpected side effects. First, even when you know it's all pro forma, praise still feels kinda awesome. Also, how you talk changes how you think. So eventually you'll come to actually believe it. Insidious!
Don't withhold newly discovered information about the customer's needs
Avoid the temptation of isolating the team in the name of "just getting* it done"
Avoid discouraging technical team members who express interest in the market or business model
Avoid over-statusing your software development initiatives
All four of these items are ways you can signal to your developers that you trust them to do their job and respect their ability to make use of the information given to them (You can't handle the truth!!). I think its worth at least being aware of this methodology in the case that you have a dev team which is showing interest in "the why" of a particular project, or appear to be struggling to build what the business is asking for. Otherwise, you are better off incentivizing devs with bonuses, pay raises, and equity because they might just not care about "the why" or "the why" might just not be useful for them to do their job.
The problem is when the vision is so confused and committee powered that nobody can resolve conflicts between teams by making strategic compromises. Software engineers are willing put up with a lot in the workplace, like everyone does.
One personal anecdote in this area. I once had a manager compliment me in my 1on1 about how I always maintain my cool during stressful events and just get things working. He asked what my strategy was. I explained it's easy to not get flustered about project issues because I don't care about the project or the company. So a project or company failing isn't any reflection on me personally, it's just a minor inconvenience. He laughed in an awkward way that you could tell he wasn't prepared for that kind of answer. He promoted me the next year.
I notice this on an open source project. There was a feature add by someone on their private branch. I asked why we didn't merge it and was told the implementation was not good enough. It was a cool hack, but inferior to doing it "right". So I started investigating the right way to implement it and a discussion followed and someone else started almost competing with me on implementation. In the end I backed off and encouraged him to complete it and that worked.
I have noticed on other occasions that when the project seems to be stagnating, doing something and opening a dialog will often bring people together to get something done.
People seem motivated by the notion that someone actually cares about their work. Go figure.
BUT... these last few years, I have come to some uncomfortable realizations. Not all software developers/engineers are indeed like what this article describes. It took me a while to understand it, but I came to realize that really investing yourself into what you're developing means taking on additional risk. To have successful insights that transcend those basic market driven requirements, you're also going to hit some foul balls. To push yourself to learn new things, to ask questions, creates risk for ego. The personalities that do not conform to what the article describes, are the first to advocate "leadership, direction, single point of contact", etc. I've realized they are sometimes codeword for "offload risk." An interesting symbiosis occurs between developers and non-developers: the doers and the deciders. Because the risk is now floating somewhere between a sort of dissociated yen and yang, both groups can comfortably offload blame/risk on the other group. Everyone wins. Except for the customers and the product. Even if it threatens the long term longevity/viability of the product, the short term optimization of comfort wins out.
Whats the secret? I have the benefit of working with nontechnical cofounders who's earned my respect. Instead of wasting my time on "going webscale" and lofty ambitions, they spend their time interacting with customers to sell the product and gather feedback. Every features request that comes back to me to create is something thats going to be used.
Of course, thats not enough. Thats just a baseline every startup should adhere to. I also have enough equity that if everything takes off like a rocket, I'll be set for life. I took the equity offer because of previous point.
I don't expect anyone reporting to me to have that level of commitment if they don't have that level of stake in the outcome. By all means, they should do the work they are being paid for but I don't expect them to do more.
It's very difficult to get excited when the CEO tries to drum up motivation for something that will make him fabulously more wealthy (if it goes well) and might mean a marginal increase in pay for me. Yeah, thanks, but no thanks.
If you want me to put in more effort than I'm already doing, you're going to need to use cold hard cash.
Firstly, people aren't going to just believe in anything. Let's face it, very few "believe" in something like Coca-Cola. Does that mean no one should work for Coca-Cola? Of course people should. (ethic of business practices aside!) Some of the work I'm sure is interesting, and despite that millions of people enjoy Coke and many would be happy being associated with it. They might even be content working for them. I don't think it's necessary to have a belief or passion in a company to do good work for them and not hate your job.
Belief is also fleeting because, if your company is successful, inevitably you will sabotage the things that made people passionate about it in the first place. Once you get corporate, stuck in your ways, and implement layers of aloof middle management, no one is going to care about your business from a personal level no matter how much company surveys will suggest the opposite. Belief is great, but you can't count on it forever. You might be able to extend that belief by being smart and not doing things that would show up in a Dilbert comic, but it's far more common that companies abandon the things that truly inspired their employees. Most businesses dilute responsibilities, get rid of most of the nonstandard perks, and fundamentally get lazy as they milk the cash cow.
What's more valuable long term is respect and trust in subordinates. If you don't foster those things in your culture, you'll inevitably get 90% complacence and yes-men and 10% semi-disgruntled performers who do most of the work. So many employers don't want to hear what the experts they've hired have to say; they disrespect them by treating them the same as sales (and sometimes the sales dept becomes the most respected) and milking as much effort as they can, disregarding any sort of estimates someone like an engineer would make.
If you don't have respect, not only will nobody care about your project, but no one will give a fuck about your project.
"We will rent office space in a new way and save the world doing it. " "We will xxx and humanity will thank us forever!!!!"
Working on a computer system should not entail adopting a religion for the company, or the CEO or whatever.
Often it is combined with en embrace of the prosperty gospel. Not only will we save the world but YOU (look into my eyes) YOU.. will become a BILLIONAIRE. $$$$$$$.
I have all my spiritual needs figured out and met. It is a job, it should not be a cult.
A much minor but slighlty related annoyance is
"Failture is not an option"
Well yes it very much is.
Someone quoting that line is a huge indicator that failure may be imminent.
As soon as I started working at something more meaningful, the feeling of burnout was orders of magnitude lighter, if not gone at all...
Software Developers, let's say I gave you a problem, and that problem was currently being solved with an O(n^2) algorithm, and it turns out that problem was taking up 50+% of your cycles, and because of how it was solved there is hard-coupling that disallowed better approaches, and that you can resolve this problem into an O(1) algorithm?
Would you want to hear about that algorithm? Because it's called communication.
The model I now think of Development teams is that you have Developers at the center, and then everyone else are teachers assisting them. A UX Designer is there not to create the UI but to teach the Developer how to go about creating the UI. He will start by creating designs, but he will allow the developer to make their own mistakes and eventually the Developer will become a Master UX Designer in his own right. This is true of every element of the Software Development LifeCycle. From technical to designing the product itself.
Once you have a Developer that understands Databases, understands Backend, Frontend, CSS, UX, understands the Product, works with the Users and dog-foods his own product, you will find the amount of time that it takes to get a superior product will drop massively. The example I like to give here is that Linus Torvalds created git in 10 days because he was a master user of Source Control and knew exactly what he needed, while Microsoft's Source Control team had worked with hundreds of developers over years and couldn't compete. When you have hundreds working on a project the ability to communicate in a depth-first-search style drops to 0, and you are left to only breadth-first-search solutions. Metcalfe's Law destroys productivity.
Meta about the article: I think it's moving forwards but it's got so much going on it's hard to pay attention to any single point.
I feel bad for people who are going to work on your team.
You seem to have some preconceived notions about managing people (and engineers specifically) that will, frankly, cause you a lot of trouble were you to implement them with your teams. Minimizing all communication will lead to a total breakdown of context - you want to strive for more of good communication (immediate team collaboration, access to stakeholders, healthy relationships with other teams) and less of bad communication (pointless meetings, status updates, cross-team blockages). Having engineers be responsible for everything is also a solid recipe for burn out and dissatisfaction, as others have pointed out. Most engineers do actually enjoy learning, but the manager's role is to encourage and provide opportunities, not to be the teacher, or appoint teachers.
I highly recommend reading existing literature on management, and not paving your own path here. Start with Camille Fournier's "The Manager's Path".
Hats! More hats! You're not a real full-stack developer unless you can do the work of eight or ten people on one salary.
I've done this, it's not sustainable.
It was framed for a reader already convinced that management of developers is not useful, but didn't make that clear.
Lesson for GP: implicitly assuming a position that your audience may not have can be confusing -- a barrier to communication
Edit: from other comments, looks like i was wrong and it was utter nonsense
Meta about your comment: Major condescending-vibe overall.
> Would you want to hear about that algorithm? Because it's called communication.
First of all, drop the patronizing tone. Second: what are you saying? Developers don't communicate? Don't communicate efficiently or correctly? Specify the thing that is wrong and your proposed solution and then it can be assessed. As it stands your first paragraph is meaningless. For what it's worth I've worked with marketing teams that have communication skills that match a random rock on the street, so this is not a developer issue. That "developers are all geeks and nerds and can't talk to people, and i'm here to fix it" is an old tired routine that needs to be dropped.
> A UX Designer is there not to create the UI but to teach the Developer how to go about creating the UI
You're assuming a random developer is: A) interested in learning UI design, B) needs to learn to design UI, and C) that whoever this random UI person wants or even can teach them. You're building too many assumptions on top of each other.
This kind of comments resembles the thinking process of a person with "product manager" position in a small/medium size company. Deep down (consciously or subconsciously) they don't really respect or see the value of the individual developer, but they see the team more like a bunch of horses going around the mill. They optimize for "the product" and throw around sophists-like pseudo-philosophical thoughts that appeal to like-minded individuals or to their bosses.
There’s some truth to that somewhat cynical description. :) But how do you organize software development without falling into that hole? A product has to make sense as a whole, and the only/easiest way to accomplish that is to make a single person responsible for its high-level specification. From there the negative cultural fallout you describe is to some extent inevitable (although you can and should counteract it of course).
Couldn’t help noticing your username implies you’re Swedish. I am too. Sometimes I get a feeling there is something about Swedish work culture that makes this worse. We have a long tradition of workers unions and collective bargaining, and everyone being replaceable is sort of taken for granted (or even encouraged). Any thoughts on this or how to get around it?
Instead we get what is essentially a Mcdonald motivation video in white collar form... telling us that we should care cause of impact, customer care, improve motor skills, blah blah.
Also, I feel like this view of software developers' motivation would have a really hard time explaining major FOSS projects.
Then there's the other bucket of people, who are just trying to make a living, but the environment makes it hard for them to do so due to it being so toxic. And this is where no amount of starry-eyed speeches will sway this group to working harder without pure cash. They're there to make money, they understand that the employer they work for are gonna get richer while they only get inflation-rate increases. These people would rather spend their time with family and friends.
For what it's worth though, based on friends who are chaplains and priests, those dying on hospital beds always tell a tale of being with friends or family, or personal events that gave them positive memories. Not a single one of those people they talked to ever spoke of how they did well at any of their jobs. And from this I think most of us fall under the second bucket. To encounter someone like Linus or Stallman who would probably talk about their work as a life achievement is probably a one-off unicorn.
I have hobbies, friends, family, etc. that I consider more important to who I am as a person than my job is. However, I still have a marginal preference for decently-paid meaningful work over well-paid meaningless work.
Perfection is in knowing everything and not having to communicate. Nobody is perfect and communication is inevitable. New domains pop-up every year. It is up to the developer to work out which domain they want to seek out next and a team of developers that have all sorts of skills will always be required. The core of my argument is that we need to empower developers to discover what will lead to efficiency. Hopefully those developers can cross-train, as the only way to lessen the load on the team is remove complexity of the application, and the only way to do that is to communicate between all of the domains. The best way to communicate is to have someone who knows all of the domains.
As others have answered, the answer is very obvious and doesn't need a lot of theorizing. Give good money and respect. Treat people as individuals (especially your mid/senior people). Accept that people will work on your team NOT because they believe in your product (they may in fact hate it) but because they need the money or the experience. This is not bad or wrong as long as they're being professional about it. Most important one is to not generalize, and to recognize nonsense that might creep into your thinking process. Most engineers have a great eye for spotting nonsense and they smell bullshit a mile away.
> as the only way to lessen the load on the team is remove complexity of the application, and the only way to do that is to communicate between all of the domains
Shaky assumptions upon shaky assumptions. These kinds of statements usually come from either a very experienced person or an extremely inexperienced one. From the substance of these statements it's obvious it's the latter and not the former.
> The best way to communicate is to have someone who knows all of the domains.
Honestly if you had started with this statement I wouldn't have replied at all because I would be 100% sure you're trolling. I can't even tell anymore. But this is way beyond unfounded.
Why not both? I'm an experienced developer with no management experience. This is exactly why I opened with "moving into". I do not believe that these are shaky assumptions, but have been proven by my development work. I am a man of many hats. Some of those hats are chiseled perfectly, some of them are rough.
The way that I work out how to go about learning things is go down a utopian path and create myself a minimal example. Many times the approach falls apart right away. When they don't, like this one has, and the world isn't already working that way, I expect that I am wrong but don't know why. So I reach out on places like Message Boards and peers in an attempt to work out why.
Unfortunately this thread has been filled with a lot of harsh responses that mostly show that I have blown peoples weirdness budgets and am outside of the Overton Window with no real substance. That may be partly my fault and I hope that I at least learned something from it.
I feel like you're just going to get stressed engineers who are stretched thin across multiple domains. This sounds horrible
If you can't connect those dots for me, you're wasting a lot of time and effort, yours, mine, and the customers who aren't going to get the right solution.
I don't care what language, database, etc. is going to be used, except how it relates to reliability and maintainability. The computer, punch card, double entry ledger, tally stick, etc. are all just ways to manage data.
This kind of thinking comes from the same kindergarten view of life which espouses only working on what you feel passionate about. If we all did that there would be an immediate shortage of shelf-fillers and cleaners. The same applies to the tech industry where a siginifcant number of fintech projects, such as HFT, contribute nothing of any real value to society. Each time I hear some startup wonk claiming he gets excited about making a better todo app I just want to throw up. The startup world is full of trivia chasing investment dollars.
I've made a point of telling interviewers that I don't believe in their product and that it shouldn't matter. I'm hired for my technical ability alone for which I have a track record of producing good work on projects in which I had no personal investment.
Clarity of goals does matter. That can make or break a project but it has nothing to do with believing in the product.
So, if passionate problem solvers are available, what comes of not using them? Insufficient solutions. Keep telling yourself you make fine systems when you don't love the project. I bet you do. But the developer who actually cares will always produce something better.
Add in that technology becomes entrenched, I'd argue we're always better working with no solution than to become attached to an inadequate one.
Before you get hung up on "inadequate", I'll also throw out there that no spec is perfect and it is only the passionate who can properly fill it in.
tl;dr projects completed by the jaded will only meet stated requirements. Projects completed by the passionate will define the actual problem in the course of solving it. Projects produced by the jaded should be discarded.
You say the developer who cares will always produce something better. Isn't that assuming parity of technical ability? Big assumption.
You don't have to be jaded to not invest in the product personally. What's wrong with just doing a good job with professional detachment? Maybe it's more the case that projects/domains vary in their scope for passion and belief. A small team working in a startup is a different world than a Java team working in a large bank where corporate structure dominates.
good? yea, maybe.
can motivated employee do something better? more likely.
If I'm working in exhausting/problematic business domain and salary is bad, then I'm not trying to outperform/save the day/yadayada
unless I really see stuff that must be improved, but generally I'm just doing my stuff and go ahead.
I don't like it, but sometimes there's boundary of how much you can mess with stuff that writing burns your hands.
The model should be chosen based on the needs of your business and your product. But, most importantly, you can't mix any match approaches. If you want teams to use creativity to build novel solutions, but your business is driven by a sales team who only want cookie cutter features on a strict deadline, you're going to have a bad time.
[1]: The useful shorthand I've used to describe engineers in this model is Product-minded Engineers: https://blog.pragmaticengineer.com/the-product-minded-engine...
If I am going to get invested, I want to be, you know, invested.
"I'm being kept in the dark and fed shit"
Which applies to a lot of dis-functional workplaces.
For those saying “I’m just here to write code for money, full stop” was that always how you approached software engineering? If not, would you choose a different career if you could do it all over again?
Very similar to how we methodology-philes talked back in the 90s. Peopleware, Mythical Man Month, Luke Hohmann's Journey of the Software Professional, etc.
Thanks for posting. IISM.org is a great find. More like this, please.
Give me equity and I'll care.
you give people some equity they want more.
or worse yet now as an owner you will comment on direction of the company since you have a vested interest. distracting the folks who are leading the company.
not saying that the leaders know what they are doing, but at least let them fail without distraction from small stake owners.
Everything else is BS.
You give me the above points I'll give my 100% from 9-5 of course.