After my first contact with a computer in the 1980's, I taught myself to program in BASIC and Z80 assembler. I went on to study Computer Science and have enjoyed a long career in Software Engineering.
I have found that before tackling a significant piece of work it can be useful to identify areas that poss a particular challenge and prototype them in isolation (away from the rest of the code base). I have done this recently, captured the code and shared my thoughts with my colleagues. The result is, more often than not, a much better solution
@tracygjg good point, I agree with you prioritizing tasks before tackling them into coding is an excellent way to identify challenges and also help you with the amount of time needed for each part.
I'm a selftaught (web) developer. On sunny days, you can find me hiking through the Teutoburg Forest, on rainy days coding or with a good fiction novel in hand.
I started to use Obsidian and its Excalidraw plugin to write specifications and UI ideas. Then, I start building a basic idea with Tailwind + Vue. More often than not, I copy/paste a lot of stuff right into the page-level of the app. When the customer (or I) like what I see, I refactor everything into components.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
This is a question on the lifecycle for designers not for developers.
To become an expert UI designer (at least through the traditional way) you'll need a college degree plus a master.
That's an entire different career.
If you -like myself- like the design world there are tones of stuff to learn as well. i.e. Color theory, shape and composition...
When working on a personal project I usually use excalidraw.com to perform low quality wireframes and that's all. Sometimes I use Adobe XD to add detail to the wireframe and design something cool on it but almost never prototype on it, just because to me is like a waste of time.
I can expend this time applying the functional in the code instead because I already know which functional do I expect it to have and how I expect it to behave.
When on a larger project within a team I expect prototypes along with the designs from the designers.
UX/UI wise the design is already provided where I work currently, so there is not much need for the devs to prototype (the designers do it though). If I do it for my own projects I prototype in paper, I draw around a credit card with a pencil for my "phone screen" (I'm an android dev)
I prototype new tech or integrations though. The current app I work on is so insanely large, over complicated, slow and flaky that when adding any significant new piece of tech, it can be hard to tell if the problems are due to the new tech, or due the legacy code that's broken for an unrelated reason.
So I've found myself doing more and more standalone prototype POC style apps to quickly settle on an optimum implementation of the new tech without being bogged down in all the cruft and 20 minute build times. It's worked really well - at the end we can almost copy and paste the implementation in to the main app, and then spend time polishing the UI instead of fixing crashes and weird bugs.
For a more reasonable app, I might do this kind of thing in a branch, but the advantage of having it separate is clarity - especially if you need to explain the implementation to someone else (or explain it to yourself ;))
That sounds like "wireframing" - a prototype would usually involve coding. If I'm sketching out UI ideas though, I use pen and paper (a reMarkable tablet)
Yeah for sure. Something at school that has been installed in us ever since I started. Definitely is something I've learnt to do in my own projects. I am a big Adobe XD fan just because I have CC, but you can never beat the simplistic pen and paper approach!
I have found that before tackling a significant piece of work it can be useful to identify areas that poss a particular challenge and prototype them in isolation (away from the rest of the code base). I have done this recently, captured the code and shared my thoughts with my colleagues. The result is, more often than not, a much better solution
Yes, same here, when I started to "draw" first than code, even if it is a CRUD, it make things easier to solve later, and to pass to my colleagues
@tracygjg good point, I agree with you prioritizing tasks before tackling them into coding is an excellent way to identify challenges and also help you with the amount of time needed for each part.
When solo problem-solving — I "prototype" with a pen and paper, but half the time it's gobbledygook.
I started to use Obsidian and its Excalidraw plugin to write specifications and UI ideas. Then, I start building a basic idea with Tailwind + Vue. More often than not, I copy/paste a lot of stuff right into the page-level of the app. When the customer (or I) like what I see, I refactor everything into components.
Nice, I've heard about Obsidian before but i wasn't aware of this feature, I will dig into this later, Thank You
This is a question on the lifecycle for designers not for developers.
To become an expert UI designer (at least through the traditional way) you'll need a college degree plus a master.
That's an entire different career.
If you -like myself- like the design world there are tones of stuff to learn as well. i.e. Color theory, shape and composition...
When working on a personal project I usually use excalidraw.com to perform low quality wireframes and that's all. Sometimes I use Adobe XD to add detail to the wireframe and design something cool on it but almost never prototype on it, just because to me is like a waste of time.
I can expend this time applying the functional in the code instead because I already know which functional do I expect it to have and how I expect it to behave.
When on a larger project within a team I expect prototypes along with the designs from the designers.
UX/UI wise the design is already provided where I work currently, so there is not much need for the devs to prototype (the designers do it though). If I do it for my own projects I prototype in paper, I draw around a credit card with a pencil for my "phone screen" (I'm an android dev)
I prototype new tech or integrations though. The current app I work on is so insanely large, over complicated, slow and flaky that when adding any significant new piece of tech, it can be hard to tell if the problems are due to the new tech, or due the legacy code that's broken for an unrelated reason.
So I've found myself doing more and more standalone prototype POC style apps to quickly settle on an optimum implementation of the new tech without being bogged down in all the cruft and 20 minute build times. It's worked really well - at the end we can almost copy and paste the implementation in to the main app, and then spend time polishing the UI instead of fixing crashes and weird bugs.
For a more reasonable app, I might do this kind of thing in a branch, but the advantage of having it separate is clarity - especially if you need to explain the implementation to someone else (or explain it to yourself ;))
I start with pen and paper, and then move onto Adobe Photoshop. I plan to learn Adobe Xd in the nearest future
YEES, it seems that you always have pen and paper by the hand!
That sounds like "wireframing" - a prototype would usually involve coding. If I'm sketching out UI ideas though, I use pen and paper (a reMarkable tablet)
After all Pen and Paper wins lol
Yeah for sure. Something at school that has been installed in us ever since I started. Definitely is something I've learnt to do in my own projects. I am a big Adobe XD fan just because I have CC, but you can never beat the simplistic pen and paper approach!
When the image is clear, I will code it first. If everything is a barebone, I will sketch first (in Figma) and play a bit to fill in more details.
Nice
For C# architecture, and code reviews, I like to prototype with LinqPad.