Embedded Files
Software Development is to me more than an hobby since I work at Airbus (Helicopters) as SW Dev. Responsible, dealing with few tools or technologies there.
It is pointless for me to pretend to properly and completely describe what it does consist in, but at least here are few typical activities: needs expression and (business) context catch (not just simple specifications listing), design and architecture, implementation (development), tests (bottom-up), documentation (not just handbook), deployment, training and promotion. This listing may infer a linear single thread development over time, but in fact it is highly recommended to parallelize and loop with little cycle with of redundancy of these activities. Such agility can be differently formalized with different names (e.g. Scrum) but at the main goal stay the same: fulfill at best user's expectations, in time / quality / cost, and even dealing with communication issues and needs changes over time... well, this is ideal theory of course.
But at the base, where is the fun to develop some SW?
Clearly, this is an inside job, you'll spend most of your time in same open space in front of your computer. You won't meet so many people, and when it does append this is not mister everyone in the way that it could change your reference when interacting with people outside of your work. Dealing daily with your computer is something bit special, working at big company (NB: not being SW editor..) is another level: you'll learn to do more with less, firstly less freedom with HW you don't necessary select and SW you probably can't install / configure yourself. I estimate currently spending 25% of my time dealing with such topic.. required to proper perform your task at the end.
Nevertheless, SW development is the best option for people skilled in technique but creative and lazy in same time. Sounds weird but true: the first will be the fuel, the second the wheel.
Many similarities can be found between building and SW architecture. Some generic issues being solved with same approaches, some design patterns have been identified to help builder or developer to adopt suitable problem solving strategy. A SW architect will have to setup the ideal resources, data structures to store and data flows to process, with flexibility (handle usage or context changes), reliability (stay available and consistent), scalability (grow in size) and resiliency (resist to failure). Related to underlying technology, programming language, development tool kit or even operating system, the same result, at least in term of user experience, can be achieved in many different ways. Here laziness enter in the game: a sexy design will be the one achieving the goals but in minimalist way, bit following principle of parsimony in science.
Or but what about creativity? Well, this is helpful, sometimes required, at different levels. For the user, the visible aspect of a SW is the "human machine interface" or HMI. Starting from scratch, you'll need creativity to design nice, powerful but still simple HMI. Once data are collected and processes configured, you'll often have to solve some tasks complexity with creativity. A generic approach may do the job, sometimes a dedicated workaround or optimization has be implemented. Finally, for test and documentation activities, a kind of creativity in term of "diversity of user behavior" help to consider most of all use cases.
Keep in mind, the user sees most of the time only a compiled binary, displaying some windows and widgets. One more time many different codes can lead to the same SW behavior, service or user experience. And to get a taste of an elegant design, the direct way is to get access to the source code.
Some language are interpreted, meaning that your SW will be in fact a source code, and to run this SW an interpreter will be required. In this particular context advanced user will have access to it, for curiosity purpose but in some cases to comment or even contribute as well.
At the end you'll find very few people having access and skilled enough to check out what's going under the hood. It means that if you're looking for showing off with what you're able to do, then you'll probably be quickly disappointed. Personally / at my level, I'm satisfied when a user is able to do his job and happy because he achieved it quicker, or found back his previous session with all the data, or impressed by an immersive experience (as virtual reality tool can offer). After that, code or architecture elegance turned out to be a personal satisfaction, that I would willingly share but current industry area is not suitable context..
Google Sites
Report abuse