Big News: FounderDating is joining OneVest to build the largest community for entrepreneurs. Details here
Latest Notifications
You have no recent recommendations.
Name
Title
 
MiniBio
FOLLOW
Title
 Followers
FOLLOW TOPIC

Question goes here

1,300 Followers

  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur

What drives software engineers crazy?

I'm following a good discussion called "what drives designers crazy?" Definitely opened my eyes to what frustrates designers, so I want to start a discussion around the same topic for software engineers. What drives you crazy? I don't want this to become a complaint thread, think of it as a way to educate your non-engineering colleagues on how to better interact.

21 Replies

Eric Wold
8
0
Eric Wold Entrepreneur
CEO @ RingSeven • Web & Mobile Dev • Startups
I'll just mention the top few I've heard from my people before.
When management:
  • Makes them move on before they can "properly" finish what they are doing
  • Does not allow any refactoring because they think it doesn't add value
  • Rapidly changing requirements
Art Yerkes
0
2
Art Yerkes Entrepreneur
Computer Software Professional
I currently work with some great designers. Design is motivated by interactions with real users and deadlines, not by aspirations or speculation. These designers use interactive wireframe tools to prototype their designs fully and demonstrate their value. I also work on a project now that uses a web front end so there are few limits on what the UI is capable of given time to engineer it. My 'drives me crazy story' isn't this one.

The experience that drove me most crazy was working on a desktop app which was highly constrained by runtime environment and download size (at the time, under 500k download and no extra dependencies on windows 2000 was required). Hiring a visual designer under those conditions was probably a mistake. However, it didn't help that our visual designer took the attitude that every design should start without technical input and then have constraints applied. Obviously, each of the designs this designer came up with was far too ambitious for this little app, and our team spent a lot of time talking down each redesign to what was achievable on our time budget. Ultimately, she didn't stay on the project very long. I'm sure she was frustrated, but her expectations also weren't in line with the technology we were working with.

My advice to designers working on existing legacy apps (especially non-web-apps) is this:
- Make your blue sky designs, but don't start flaunting them around your engineers until you know where you can get to. Use these as guiding principles when you come up with smaller, more realistic ideas. Spread out these improvements, and over time, you'll start getting what you want.
- Find ways to improve the app's usability without changing the UI technology unless you have a lot of engineers on board or the software design is internally well decoupled. Ask around: you might find that you can get good or better looking visuals out of old technologies if you cooperate with engineers on specific elements.
- Most desktop apps have widgets that look the way they do because they come with the windowing system. People make an effort to make them look authentic. Know that there's engineering effort to making controls that don't look native (and especially window and dialog borders).
- Engineers who normally work on system software, network software, etc often aren't as familiar with UI technology. Encourage project leaders to set time aside to make proof of concept demos when you try to introduce new technology. The knowledge gained from these needs to be acquired sometime and by the team you have. If it turns out to take too long to make the prototype, you might not be fighting the right battle.
- If you must change UI technology, build a coalition around it, and always opt for HTML if possible. Know (really know and understand) that if HTML is being embedded in part of the application, you might be stuck with inferior and inconsistent browser technology (safari, IE6, android builtin). Also know that you've got it 500 times better than with a native UI, so don't complain. Also know that this doesn't get you fancy window borders; that's extra work.
- Ultimately, designers are on the team just like engineers. Everybody has pie in the sky ideas they know there's no time for. Everybody has the responsibility to come up with ideas that are realistic, actually beneficial, and can be done with the project's budget.
Eric Wold
7
0
Eric Wold Entrepreneur
CEO @ RingSeven • Web & Mobile Dev • Startups
Oh how did I forget this one:
  • They want to be told the goal and be free to choose their own implementation/solution. Drives them crazy when non-coders try to tell them HOW or HOW NOT to solve an issue.
Rick Stratton
1
1
Rick Stratton Entrepreneur
Great States Software / Feed.Us / MKEcribs
Building some piece of code that takes time and thought and then never gets implemented or used within the greater service.

That's maddening.
Michael Barnathan
2
0
Michael Barnathan Entrepreneur • Advisor
Co-Founder of The Mountaintop Program, Google Alum
My #1 pet peeve is working with founders who micromanage the project and need to be in constant communication about it - particularly if that communication involves changing direction often. Keeps me out of a flow state and makes it harder to actually get the work done.

#2 would probably be the "perpetual MVP", which stays alive but never graduates into an actual product. If an MVP works, the idea is usually that you want to develop it further into a solid product, not move onto another MVP. And if it doesn't, you shouldn't keep maintaining it; scrap it and move on.
Seth Caldwell
1
1
Seth Caldwell Entrepreneur
Creator SnapChallenge
https://www.youtube.com/embed/BKorP55Aqvg sums up several things that drive us crazy. In essence though, an odd combination of stupidity and acknowledgement of it.
An example: the start button. How many people still use their mouse to click it when we have a keyboard key for it?! I finally got my mother to change her behavior on this, but people who refuse to change their perception or behavior in ways THEY KNOW are inferior is the seed of the most frustrating thing on the planet for me. If you put a good dev on a team with a bad dev where the bad dev is in control of a part of the project and the good dev has to code around them and they continue implementing bad things they know are bad, the good dev has proved are bad and shown how to do them better, the good dev will lose his mind no matter what he's being paid.

Caner Öncü
2
0
Caner Öncü Entrepreneur
Software Developer - OBSS
  • Micro-management
  • Non-stop change of requirements
Madness!
Charlie Pham
4
0
Charlie Pham Entrepreneur
I have passions in film, music, web and geeky things
Constantly asking if its done yet.

No it isn't because requirements keep changing. stop asking...you should know better
John Arroyo
1
0
John Arroyo Entrepreneur • Advisor
Delivering ecommerce and cloud applications, CEO of Arroyo Labs
I want to build on what @eric already said. He touched on the top 4.

Being indecisive is not "pivoting". Changing your direction midstream before something is done has to be strategic and infrequent. It's very frustrating for the developer when specs keep changing mid sprint, if done too much it can de destructive to your product too and lead to unintentional spaghetti code. In extreme cases it leads to nasty bugs and developers that leave.

A fifth pet peeve would be lack of appreciation after a difficult sprint. If your developer makes a Hail Mary pass to build within your crazy constructs, take minute to appreciate the progress of the team. Don't use that success to justify requiring another Hail Mary for the next sprint. That's how programmers burn out.

The appreciation doesn't have to be verbal (although maybee it should be). Giving the developers a sane sprint load after a very hectic one shows you give a shit.

Diego Cardozo
0
0
Diego Cardozo Entrepreneur
Developer
Copy & Paste code, I hate when people do that.
Join FounderDating to participate in the discussion
Nothing gets posted to LinkedIn and your information will not be shared.

Just a few more details please.

DO: Start a discussion, share a resource, or ask a question related to entrepreneurship.
DON'T: Post about prohibited topics such as recruiting, cofounder wanted, check out my product
or feedback on the FD site (you can send this to us directly info@founderdating.com).
See the Community Code of Conduct for more details.

Title

Give your question or discussion topic a great title, make it catchy and succinct.

Details

Make sure what you're about to say is specific and relevant - you'll get better responses.

Topics

Tag your discussion so you get more relevant responses.

Question goes here

1,300 Followers

  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
Know someone who should answer this question? Enter their email below
Stay current and follow these discussion topics?