Technology Lab —

I can write code, but can’t design well. Any help?

Reading books can only get you so far—and sometimes that's just far enough.

Stack Exchange

user396089 is more than competent when it comes to writing code in "bits and pieces." Planning and synthesizing that code into a complex, coherent app is the hard part. "So, my question is, how do I improve my design skills," he asks. And to that, some more experienced programmers answered...

See the original question here.

Be a bad designer for a bit

Amadeus Hein Answers (8 votes):

Well, there's no golden apple for this kind of question, and I feel perhaps this is for every coder himself to find what's right for him. Here's my take, anyway.

You could read books on the subject. Great books. Fantastic books. But I find that these books only help you once you've tried to build and design an application—and failed.

For me, it's all about experience. When I started as a rookie I read books on how to design. I didn't understand much of the content back then. When I started working and had to design applications myself, I made very messy applications. They worked, but they were a pain to maintain. Then I read those books again—and this time I better understood them.

Now, I continue making new mistakes and learning from the old ones.


Stick to some basic rules

Konrad Morawski Answers (4 votes):

Read about patterns, sure, but first and foremost read about anti-patterns. Recognizing anti-patterns is important, and it's easier to understand why something shouldn't be done in such a way than why it should.

See SourceMaking's post on anti-patterns, for example.

Write code so that it can be adjusted quickly if requirements changed (which is very common in production environment).

Be super-skeptical about adding "just one more little hack." One more here, one more there, and the code becomes unmaintanable.

Value the open/closed principle.

Write tests (as in TDD). They force you to think your design through even before you actually implement it.

Browse the code of open source projects (reasonably sized ones, that is). I used to be surprised at—usually—seeing so many levels of abstraction. Now I understand it's not art for art's sake, there's a reason why it's done this way.

Decompose it

Giorgio Answers (3 votes):

One principle that I find very important for good design is decomposition:

  • If a class is too big (more than, say, 300-400 lines of code) break it up into smaller classes.
  • If a method is too big (say, more than 50 lines of code) decompose it; if a project contains more than 50 classes, decompose it.

The key is to estimate the size of your system and construct several abstraction layers (e.g. subsystem, application, project, module, class, method) that allow you to decompose your code into understandable units with clear relationships between them and few dependencies.

Forget about design

kevin cline Answers (2 votes):

Stop designing and learn to refactor code. Incremental development with continuous and aggressive refactoring will result in a much cleaner end product than any up-front design.


40 Reader Comments

  1. Design from the bottom up.
    Start by building the backend functionality.
    Then the front-end.

    Front-ends can take all kinds of shapes and forms, the back end, the business logic, is where the rubber hits the road.

    1) run the back end from a batch job, with command line input.
    2) A Web service
    3) An application
    4) A Web site front end.
    174 posts | registered
  2. Maybe the OP needs to learn the skills of being a better writer? To write a good story isn't just about the mechanics of writing, but being able to see a big picture, and breaking it down, and articulating it so his/her audience can understand it. Be immersed in it.
    27188 posts | registered
  3. Learn to read music.
    332 posts | registered
  4. Ostracus wrote:

    Elegant design is quite different than writing and is more than just conceptualizing the problem into abstract building blocks. For example, a great programmer identifies and isolates chunks of code they anticipate will change. It's a skill that's earned with experience after making a lot of bad decisions.
    3 posts | registered
  5. Anyone has any tips on how to begin? I always wanted to start, but for some reason, coding seems intimidating...
    8 posts | registered
  6. Nelsk wrote:
    Ostracus wrote:


    Well aside from me trying to not repeat advice already given. It sounds like the OP falls a level below systems architect.
    27188 posts | registered
  7. Marcus100 wrote:

    Start with a simple problem you're trying to solve. Try to understand it thoroughly. The rest is choosing your particular tool. Some people like Python for example. Look over others code. Asking, why did they do that? Make lots of mistakes.
    27188 posts | registered
  8. Looks like, mostly, sound advice, although I don't quite agree with the "forget about design" in favor of pure iteration comment: accepting refactoring and iteration is important and necessary, but in my experience code developed in this manner without any kind of architecture or design process ends up being good at one very specific thing and can be difficult to extend into adjacent use cases. Sometimes that matters and sometimes that doesn't, but if you expect your code to be an annuity that you can draw on over a multi-year lifespan you had best do a little up front thinking about how it's going to fit together and how it's likely to be used over the long term.

    Honestly, it's hard to provide a single answer to this question: the process required to design a simple discrete app is very different from the process necessary to design/architect a big, cloud-based enterprise application with a lot of moving parts and significant scalability and/or availability requirements.

    Basic advice: try to decompose your problem or business process into a finite set of actors - if possible do it in such a way that you could explain how your app works, using these actors, to a non-technical person. Then, express those actors as a set of loosely coupled components. By loosely coupled, I mean that they should interact exclusively though well-defined interfaces (how you express these interfaces depends on your development platform), Think a bit about what these interfaces should look like. In fact, defining them first (design by contract) is not a bad idea, nor is writing tests to those interface designs up front. Finally work on implementation. Be prepared to change and refactor your design as you encounter issues during implementation.
    7 posts | registered
  9. [Derp,]

    Last edited by BoogerGooberBoober on Sat Apr 13, 2013 10:07 am

    299 posts | registered
  10. One step I think is overlooked is to step back and try to get the full picture of the app answering such questions:

    0. Do not consider how to write any code, classes, etc. Ignore the temptation to provide details

    1. What is the app doing/used for? What activities will a user being with the app?

    2. Who is primarily using the app? What is the computer literacy/expected skill level? For specialized apps, are there any conventions the user is expecting?

    3. How the users interacting with the app? Browser/conventional desktop?

    4. Consider the data and how it should be modeled. Here it is broad categories. For example for a retail customer order entry one needs customer info, shipping info, order details, and payment info. Question to ask is "Did I overlook a category"? At this point you do not care about the details. For example you do not care how the customer pays only that you have a mechanism for payment. Further details would be added at lower levels. The next level may be payment by credit/debit card. Further levels of detail would focus on which credit cards, customer input, and verification.

    5. How does information move through the system? What most happen and in what order for the process to work correctly? Again keep the it broad. For the retail customer they may be looking for a very specific item, say computer memory, or they may be browsing by topic/category.

    6. Review the overall for completeness of process.

    7. Move the next logical level and repeat process.

    One trick may be to do the initial design "doodle" using literally pen and paper to avoid the temptation to jump in and code.
    891 posts | registered
  11. It's hard to overestimate the importance of "seat-time" in becoming a good designer. Good design comes from experience; knowing what has worked for you before and what has failed. You can learn rules of thumb, and within a good team that will take you a long way. But experience has to be incrementally acquired.

    There *are* a couple of books on object-oriented design. I recommend books by Rebecca Wirfs-Brock as complete and not too heavy. I used this classic text to teach a whole dev team object oriented development. It's language-independent and not at all dated even though it was written 25 years ago. It is however ridiculously expensive if you buy it new. Maybe her more modern text covers the same ground. ... 0136298257

    I second the nomination for Test Driven Development. Nothing like having to actually use your class to wring out issues in design. What? Your class requires pulling in half the code base to test? Well, that's a design problem right there.

    Here's a hint. You don't need to master some big test harness like boost::test or cpptest. Each class can have a single method "static bool ModuleTest(int test_number);" that you can use to test and exercise your code. The linker won't include this code in your final program unless something else in your program accesses it. For testing, have main() call this method. You can comment out the test when it's working.

    I don't agree with the advice to look at open source code unless there is someone you trust to point you at good code. There is a whole lot of trash code out there, and a lot of useful code written by inexperienced developers and astronomers with no CS training, etc. Not every writer wins a Pulitzer prize. If you want to learn how to write, you have to look at writers who are good.

    I think writing down what you plan to do before you start slinging code is a pathway to becoming a designer. The problem is, it's tedious and hard. Just like good design. I'm a very experienced developer, but even so, it takes me three times as long to build a beautiful, long-lasting interface as it does to make *something* that works.

    That brings me to my last point. Not every piece of code you write needs to be well designed. Most employers place a premium on getting functioning code into the marketplace quickly. Quality is of secondary importance. Maintainability is almost not important at all. If the product doesn't make it to market because it took too long to build, its quality and maintainability is irrelevant. And if the product succeeds in the market, improving it is maybe not necessary. It's only if your product is an API, tool, or library used by other developers that it gets points for good design. I hate saying these words, because I love good design. But they are true enough.
    46 posts | registered
  12. In my personal opinion development should be Top > Down ( Presentation > Business > Data ).

    You should only do Down > Top if you are quite experienced in development and the target business area.

    Why ?

    - Understanding the client needs and requirements.

    If the client himself doesn't understand what he wants, starting Top > Down will force him to specify it upfront. There will be a clear defined goal.
    It will also decrease the probability of changing requirements in the middle of the project since he has already clarified the idea.

    - Front loading most of the work with Planning ( Prototypes and Mocking ).

    Its easy to change things on paper but quite hard on implemented code.
    Architecture needs to be planned for a purpose, even if that purpose is to be as modular and abstract as possible.
    Every Design Pattern has pros and cons, which one will you use if you don't know your goal ?

    - Modularity and Abstraction

    You will have a clear well defined point from where to expand.
    If i know that two things will need to share the same base, i can design that base to be shared by both. Starting by doing a base that can be used by anything is unnecessary work based on pure guesses.

    - Develop in small chunks
    Planning big has a lot of downfalls as well. We can't plan everything. I always develop a skeleton base and go from there, step by step.

    This is the reason why TDD forces you to do tests first. To force you to specify your needs before developing code.

    Keep in mind however that Iteration will always be your best friend. Code can always be improved and planning has its downfalls.

    However there is a difference from Iterating a solid project and Iterating junk.

    Last edited by eviloop on Sun Apr 14, 2013 5:16 am

    3 posts | registered
  13. From what I've seen working at various consultancies in a non-tech role, it's indeed hard to go from writing good code to designing projects well. Especially because 1- coming from writing code, you get lost in details early on, starting to write your project before it is even designed, and 2- because you write good code, you expect good code, and fail to budget for slow and buggy.

    Designing and coding are really 2 very different skillsets. You can try to move up from coding gradually, but in my mind, you might as well forget all you know (well, almost ^^) and go full top-down.

    Your big advantage as a coder, is that you must know a few good designers. Pick their brains, even if it costs you a few lunches. Try your hand at some side projects (you don't want to ruin your reputation by messing up "live"), and ask for their off-the-record feedback on what you've come up with.
    1284 posts | registered
  14. Marcus100 wrote:

    If you are new to programming, scripting languages are a great place to start learning. Also, start by running the program itself (e.g. run "python"). This will start you in an interpreter that will run whatever you type immediately after you press enter. This is great for learning the basics and experimenting.

    For example 'a = 5' creates a variable (a named value) that stores the numeric value 5. After this, entering 'a' will display '5'. You can perform mathematical operations on the variables, e.g. 'a*a' will print '25'. Keep building it up like that.

    Read through tutorials. Type in the examples and run them to see what they do. Modify the examples (e.g. try printing the cube of 'a'). Stick with a topic until you have a firm grasp of it -- don't try something new that uses that topic.

    Try and get a feel for the underlying concept the program/language is trying to do. The syntax of the language (how it is written) varies, but the languages share common concepts. Once you grasp a concept, it should be easier to transfer it to other languages.

    When you get to algorithms and data structures, try adding print statements in different places. This will help you see what is happening to the different variables over the course of the algorithms.

    You can also experiment with JavaScript and the HTML5 canvas. I know people dislike JavaScript, but this is a good way of creating dynamic programs - being able to draw shapes and animate them.

    As you gain confidence, you can learn other languages like C, C++ and Java. If you are learning C++, C++11 has a lot of new features that make it easier to learn/write. The gcc (4.7 or later) and clang (3.2 or later) have near-complete support for all C++11 features.
    639 posts | registered
  15. I would say code for yourself,

    Not only are you working on something you think could make your own life more easy, but you'll also know exactly what you want. Coding something for personal use is always far more enjoyable which is how I've been learning.

    Everything I do and learn is pretty much Photoshop related JS, but I am learning plenty of useful things that can later translate past PS.
    1077 posts | registered
  16. Good design requires understanding your requirements (what the program is supposed to do). Also, no matter how much up-front design you do, the design will *always* change. You will encounter new requirements as the project matures, parts of the code will become harder to work with and the environment you are programming to will throw road blocks in your way.

    There are also different levels of design. The top-level design is the big picture of how the program is structured. Is it a 3-tiered database - server - UI architecture? Are you using a Model - View - Controller setup? What platform and technology are you targetting (Linux/GTK, C++/Qt, Windows/COM, Windows/C#, HTML/JavaScript, etc.)?

    There is also low-level design -- e.g. the choice of algorithms and data structures.

    Be aware of where you are writing similar pieces of code, then think about how it is being used now and how it could be used in the future. If you have repeated code that is operating on different instances of a class, wrap it up in a function or convert it into a loop. If they are different classes with a similar interface, create an interface that describes that, or create a template/generic function.

    Also, when introducing patterns be aware of their advantages and disadvasntages. Remember: not everything is a Factory and not every function needs to be in a class (unless you are in a language like C# or Java).

    Learn the idioms and patterns of the language you are using and take advantage of them where they make sense [1]. In C++, this means things like iterators and operator overloading. In COM this means understanding the available interfaces and how they can be used (e.g. IStream and IObjectWithSite). In C# this means things like IEnumerable and IComparable.

    [1] This is the thing that annoys me about CppUnit. It is a port of the Java JUnit testing library, but sticks to Java idioms :shudders:.
    639 posts | registered
  17. You can teach most anyone to code, but you can't teach much about design. Experience helps but that only goes so far. I think that a person is either born with it or they're not. It's like you can learn the fundamentals of painting but few see their paintings in an art gallery with a decent price tag on it.
    146 posts | registered
  18. Wingsy wrote:

    Experience helps, but you need to read and understand material on different design topics.

    Read about different architectures, like the 3-tier architectire, Model-View-Controller and Model-View-ViewModel and REST.

    Read about different design patterns (Factory, Observer, Singleton) including when to use them, when not to use them and what problem they are solving.

    Read about different data structures and algorithms, where to apply them and what their performance (memory and time) characteristics are. Understand how to analyse different data structures and algorithms in terms of their O() notation, how to profile and measure performance and use all that to guide your choices. Understand how to apply this when writing your own data structures and algorithms.

    Understand the different techniques like iteration and recursion. Understand the different ways you can iterate over items (e.g. see ... e-and-out/) -- external vs internal iterators, generators and coroutines. Understand how a push vs pull model works and where to apply them.

    Understand the difference between the XML DOM (load everything into a tree), SAX (push model) and reader (pull model) parsers, including (a) memory and time characteristics (b) complexity implementing the parser and (c) complexity using the parser.

    Understand the difference between synchronous and asynchronous operations (esp. I/O) and where to use them. Understand other constraints placed on you by the system (e.g. UI actions performed on the same UI thread) and how that affects the implementation.

    Understand the different libraries available for your programming language (e.g. STL for C++, QtWidgets and QML for Qt, etc.). Research how the libraries are designed. including what worked and what didn't.

    Also, you learn a lot about design by understanding what is wrong with your current design and seeing how you can fix it.
    639 posts | registered
  19. - Apply your math. Good aesthetic design is often just using ratios and patterns to place objects or complement colors. Various ratios derived from the Fibonacci sequence and right triangles are a great place to start.

    - Compartmentalize. Break your design or code into sections. Refine from the top-down. Let's say I wanted to design a website for a nature preserve website. What would it contain? A map and direction on how to get there. A page on how to volunteer or donate money. Contact information. A guidebook on what species to look out for. What should go on every page? That layout should go into a main.css. What does the homepage look like? That should go into a homepage.css, but the homepage should also include a link to main.css before homepage.css. What do the guidebook pages look like? That should go into a guidebook.css. Etc.

    - When writing programming code, think action verbs. Break up your program into specific actions that can be generalized as much as possible. Say you wanted an interactive game on your nature preserve website. You could have server scripts such as ask.php, answer.php, image.php, playCall.php,

    - Generalize wherever possible. You will find that you are writing the same stuff over and over again, be it programming code or html/css code. You should have things like reset.css that normalizes the CSS functionality of all web browsers used for every web project or (create, read, update, and delete module) that handles all the SQL to manipulate a database.

    - Avoid hacks and undocumented code. The best way to do this is to write your documentation and test code that calls your functions with boundary cases, garbage, and real data before you write the actual functional code. It's hard at first because there's a strong desire to just "get 'er done", but once you get into the habit of vomiting your ideas down on digital paper instead of translating them into code in your head, the code will write itself and you will spend less time recoding as the design changes in response to wrestling the devil out of the details.

    - Keep it simple. The worst websites and program interfaces are the ones that either deviate from accepted standards, or attempt to be all things to all people. Options are great, but more often than not, the average user doesn't need to change the kerneling on the font they see in the status bar.
    60 posts | registered
  20. The best advice is to take the requirements for the specific project to someone who has much experience designing similar software and ask them how they would do it. If this is an option available to you it is worth taking advantage of for the first few projects you do.

    Working on large projects helps too, especially if you have good variety. Look at how they did it, what you feel worked well, and what did not.

    Realize that a good design depends heavily upon what you are doing and what your resources are. There is no single right answer, or process you can follow to always come up with a good design.

    A good design for a web content management system which will be implemented by half a dozen developers in PHP is very different from a good design for a machine control program which you will write personally in C, which is very different from a large financial processing system in COBOL which is being maintained by a department including a couple of floors of a large office building.

    The one generic piece of advice that always applies is to define the project as best you can.

    This includes:
    1) what it must do
    2) what it would be nice if it could do, but is optional
    3) what may be required in the future (or may change significantly during development)
    4) what is unknown and will need to be determined while developing it based on feedback
    5) how long you have
    6) what resources are at your disposal
    7) what other constraints you have due to external factors

    The original question as linked implies that most projects you have worked on are only a couple thousand lines. It will not really show if a design is good or bad at that point, and I would probably just sit down and write it.

    I would consider a medium sized project to start at something like 20k - 50k lines of code (depending upon the language and what it does.) This is about the point where design starts to really matter.

    For an example of a large system, I once worked on one that had over 20 million LOC (I covered my office walls in printouts noting what order programs ran in, and what files they touched.)

    Looking back at some of my older designs, they differ greatly from what I would do now after 20 years. I would not exactly describe them as bad, but definitely inexperienced.
    1563 posts | registered
  21. A lot of comments (in the article itself and the comments here) talk about ways to write code better (e.g., patterns and anti-patterns). While that is good advice, you need to start at the higher level.

    The initial design should be independent of code (ideally, the choice of which language to code in should follow from the design, not vice-versa - but I know that's rarely the case in practice). Determine what the goals of the system are, and how the system will be used (e.g., inputs/outputs). Next, consider what the components of the system are, what their roles are and how they communicate with each other. This will help define the various modules and their APIs. Each module should do as few things as possible (e.g., the Unix approach of programs doing exactly one thing but doing it very well) sharing the bare minimum amount of information with other modules.

    The act of coding each module via various levels of abstraction, etc is secondary design and should follow more easily once you have a good idea what the behaviour of each component/module should be. Additionally, it should be possible to write tests which verify this behaviour (in pseudocode) before you write a single line of actual code.

    And finally, make sure you have access to a good-sized whiteboard. Personally, I find whiteboards incredibly useful for sketching out designs and discussing ideas, etc with co-workers.
    194 posts | registered
  22. Marcus100 wrote:

    Like someone else said, just start with something small, a problem that you find interesting and that you can solve through code. One of the first things I wrote was a Java program that would turn a text like "the quick brown fox jumped over the lazy dog" into "the qicuk bowrn fox jmpued oevr the lzay dog" to showcase the well known phenomenon that the order of the letters in a word doesn't matter as long as the first and last letter are in the right position. It was undoubtedly bad, inefficient code, but it got the ball rolling for me.

    Start small.

    As for the topic: one of the reasons I love coding is because it's both a hard science and a soft art. There's predictable outcomes, a clear distinction between correct and incorrect programs, yet there's still aesthetics and creativity involved. When it comes to design, it's simply a matter of "does this feel right" for me, it's mostly intuition and I find that the best way to train your intuition is simply experience. Looking back on code I wrote even a year back I often think "whhaattt?" If you look at your code and it doesn't feel right, make it feel right. If you can't find a way to do that, that's where the reading books and tutorials comes in. If you come across an idea that feels elegant and simple to you, then it's a good chance that's a good design. Just beware of "when you have a hammer everything starts to look like a nail" habit (so: if you find an elegant cool idea, it doesn't mean you need to use it everywhere) and over-engineering. You can apply all the design patterns in the world, but if it makes your code more complicated, don't.

    Last edited by PervertRyan on Sat Apr 13, 2013 2:10 pm

    426 posts | registered
  23. What a horrible story.

    Seriously get a designer and don't believe you coders can design. I've seen so many people attempt this and fail.
    2 posts | registered
  24. razordreamz wrote:
    What a horrible story.


    Did you even read the story then? It's not about visual design, but about engineering.
    426 posts | registered
  25. I've been designing and building complex systems for over 30 years. If there is one thing I have learned is that you need to have a good understanding of the problem you are trying to solve, and it's domain. For simple problems, just getting into coding it, and then refactoring (and refactoring (and refactoring ...)) will probably work ok. However, it is rare in my experience that you don't eventually get to the point where you need a real design in order to, at the least, understand how all the bits and pieces are related and interact. For this, I use serious XML modeling tools. A great tool, such as Sparx Enterprise Architect, will let you take your existing code and turn that into a UML model with forward/reverse engineering capabilities (turn models into code, and code into models). These graphical models will help tremendously in being able to visualize how the system works.
    311 posts | registered
  26. This is my problem alright.
    191 posts | registered
  27. Learn how to write code for managing your code. Different discipline in itself and it can be learned just like any other library. For me it really comes down to risk aversion. Sure the libraries like Unity add overhead in terms of lines of code, but all things considered to be able to plug in plug out bits on demand is worth the extra effort no matter how small the project.
    5450 posts | registered
  28. Funny... I like this article. I started as an applications developer back in the '80's and worked up to an OS / systems developer in the mid '90's... now I am a web developer.

    But admittedly my ideas of a good UI and our business ideas of a good UI are in conflict. I prefer simplicity (I was also a textbook and journal designer in the late '80's so my ideas consist of simple design, lots of white space - based on research on how the human eye's perceive text and graphics and how they perform better under specific circumstances) and consistency. But often people want more complexity, pretty graphical transitions and other things that just sort of rub me the wrong way.

    I really do wish my ideas of UI design were more "flexible" now.
    201 posts | registered
  29. I read a lot of Peter Norton assembly language programming books back in the 80's and 90's

    His method was to hack it out anyway you can. Just make it work even if you have to kludge it (within reason). Then after you get it doing what it is supposed to do, then clean it up and get it ready to talk to the other modules.

    He said his code was always dirty and messy while he was designing something. Write first, then clean it up and optimize it last.
    141 posts | registered
  30. MIkeOneOfOne wrote:
    Design from the bottom up.
    Start by building the backend functionality.
    Then the front-end.

    That works for me too. I have tried and tried to top-down and have only been able to do it with small programs. So I just write the bottom parts I know I will need, and then work up.

    The reasoning for me is, you come across too many unknowns going top-down, when you know for sure what you need when you start at the bottom. This way I get programming right away. Otherwise I waste too much time screwing around with unknowns.

    From there you just need to write the UI.
    141 posts | registered
  31. I think it takes time to learn to design well. The more I code, and the more good code from others that I work with, the better I get at seeing how code should be organized. Now when I have a task I am better at figuring out how to organize the code right from the start.

    It's also good to look into some good programming principles. MVC is really cool, Apple uses it for Mac and iOS programming, and it works really well in PHP too. Use objects (if it's an OO language) and read about how to properly split up your classes. Use an abstraction layer between you and the database. Don't repeat yourself - use functions/methods. Functions/methods should do one thing and do it well.
    138 posts | registered
  32. perhaps i'm misunderstanding the question. is this meant as a purely technical question or are you akingabout the holistic approachwhich is code + visual design?

    Those are quite different.

    The way i go about designing a site is:

    1. decide what you need/want in terms of features.

    2. mock a design in photoshop or whatever program. plan the skeleton and flow in PowerPoint or whatever software works. you can also simply sketch manually.

    3. after that, THEN do what everyone says. doing the above steps will help define what you need to doandhowyou should go about it in the code.
    998 posts | registered
  33. I'm a big fan of prototyping code that I either can't be bothered designing before hand, or am not completely sure about (i.e - I don't know enough about what the code needs to do yet to come up with a design that will work).

    Sometimes just throwing yourself into coding some, or all, of something is the best way, and once you have a good idea of what the code needs to actually do, you can start coming up with an informed design and copy-pasting usable bits across or just start from scratch with a clearer picture of what needs to be done.

    Nothing is worse than project where someone has designed all the interfaces you need to implement, but didn't fully appreciate what needs to happen to make that interface a reality, which can leave you with asynchronous code masquerading as synchronous, or other fundamental flaws with an interface that might have seemed reasonable until you get into the actual details of the thing.

    I also like to try to design in stages; i.e - identify the stuff that you know you can just get stuck into, then every so often take a break to think about what comes next and try to hash out a plan for it. Figure out algorithms, resource constraints and so-on.
    1804 posts | registered
  34. If you have time, participate in an open source project, see how it is structured and evolves. Chances are if it's a successful project it will serve as a great template for your own private (or public) work.
    9 posts | registered
  35. Use other people's designs. Find web sites or software that do what you do and use their design principles. Make changes so your design is unique. That's how most stuff gets done. True originality isn't necessary in almost all cases. Most work is reinventing the wheel. That's why most platforms have a framework that implements their look and feel, from the Objective-C stuff on iOS to jQuery.
    527 posts | registered
  36. I pity the hapless coder. What a boring career.
    335 posts | registered
  37. Haha, I thought OP meant design as in UI!
    42 posts | registered
  38. MIkeOneOfOne wrote:
    Design from the bottom up.

    It's funny: I tend to design the other way round. I first write simple code expressing my problem at the highest level and using theoretical classes and APIs that I've not yet written. Of course, this code does not compile.

    I play with this code a bit, trying to find the most expressive, concise and reusable way to express my needs, then I create the API interface and redo the process for the implementation of the API, that can then be coded against a lower level API that doesn't exist yet, and so on...
    95 posts | registered
  39. Work with someone who is better at that aspect then you. Not everyone can be good at everything.
    150 posts | registered

You must to comment.