there is a difference between knowing computers, and knowing how people use computers. you'd do well as an engineer to understand this difference, and invest time into learning and educating about both. foss software will never be on the same playing field as the corporations who understand this distinction until it's contributors do too
(cont.)
you'd think this would be an obvious statement but there is a certain, prominent breed of stembrain that does not understand this. the reduction of software development to pure engineering creates this massive blindspot in the vision of engineers that fall into this mindset. education material for new engineers is always focused on the technical aspects. what's the most efficient algorithm for a given use case? what's the new abstraction/library/framework of the day, and what's it's technical merits? what are the best strategies to ensure a clean, maintainable code base?
i cannot stress enough that the end user does not give a single flying fuck about any of this (well, maybe a little - only insofar as the software actually functions, and performs reasonably). whether you filter an array of search results by iterating over the array with a for loop, or a filter function means absolutely fucking nothing if the user doesn't even understand how to access the search functionality in the first place. there are established interaction patterns in use across applications - some good, some bad. but an engineer's education ignores this. it's not technical work. it's not engineering. it's design. that's not your concern. you're learning a STEM subject. not a creative one. you don't need to care about that. it's not your job, that's the job of other people you'll work alongside in the industry, so they'll take care of it. just focus on shipping production-ready code, that's all we need from you.
...you are learning so you can get a job in the industry, right?
the foss scene is made up almost exclusively of engineers. particularly, career engineers who contribute to foss as a hobby on the side, or as portfolio projects for their resumes, or even as part of their job sometimes. designers don't enter the picture very often (and we should really ask ourselves why that's the case sometime). what that leaves foss with is a bunch of engineers making software for no-one in particular. there is no target audience, there is no user research, there is no intentional design - only architectural decisions without enough ux consideration to keep the user a safe distance from the limb-crushing heavy machinery contained within. and we can't blame them - this is a skillset they were never taught, one they were taught they didn't need to care about.
we need to break this tradition, if we want foss to be viable for the everyday user. we cannot keep producing functional but unusable software (in the best case), and then putting it in front of users, expecting them to choose us over photoshop, or maya, or ableton, or <insert program here>. this is software built by companies who have hired people to fill the gaps that their engineers left - we can't compete if we can't fill those gaps. so please, if you are a software engineer, learn some ux design. learn some accessibility guidelines. learn who your users are, and what they need from your software. even better if you can learn them well enough to teach others. because again - we will never be on the same playing field as proprietary software funded by monopolistic corporations until we can give people software that they can look at, and want to use.
