|
|
|
|
|
|
by jrockway
2490 days ago
|
|
|
Yes, I pretty much have a mental model of what I want to build before I build it. I am not sure that I build the mental model in 30 minutes, though; rather I get an idea, think about it over the course of many days, talk with people about it, write down some design details, etc. Only after all of that does any programming begin, and the actual coding is then the easy part. You know what data structures you need. You know what the external API will look like. You know how to deal with the tricky parts; be it integration or some sort of unusually complex algorithm. Doing the design work is what separates senior and non-senior engineers. The more details you get worked out before they are solidified by having 10 other systems depending on them, the better. If you just do stuff with a rough idea of the direction you want to go in, it's very easy to get sidetracked by something that doesn't matter. It's also very easy to build something nobody wants. By having people agree on some sort of semi-detailed design that describes assumptions, corner cases, the API, etc... you dramatically increase your chances of building the computer program that people want. I am not sure how you test for this in an interview... but it is important. If you don't design things before building them, that is something you should start working on. |
|
|
Usually, I'll think about a problem, some of the inherent characteristics, or desired behaviours then choose some applicable techniques/technologies, languages, algorithms, libraries. Then think about how to compose the program from parts to be developed. This all happens naturally without conscious sequencing.
That's what's great about being current here, I find out about things I don't need to use yet but could be useful at a later time. Or discover something that would have made a past project better if I'd known of it.