A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I'm currently following after hour courses to get a basic 3 year degree in software development. This course covers a lot of the basics (on college level) from computer programming in .NET, SQLserver, databases, network management to organisation and communicatie techniques. It's a pretty well covering course. However since it's wide, it probably isn't going to be very deep (again for a college level course). Therefor I'd like to ask what skills I should learn and practice to be able to develop real world software and what are the dependencies between those skills. I'd especially like to know what skills are often neglected in education but needed in real life.
Thank you for your time and advice
as far as I'm concerned: I studied in Germany at an university. There I learned a lot about algorithms and the design of software (e.g. designpatterns and so on) but what really was missing was knowledge about projectmanagement (you have a project and if it is only the project: "implement an user management") and, on top of this, a profound knowledge about requirements engineering (what should that feature really do?). If you will just be a programmer then you do not need that, but if you really wish to develop, you have to manage your project, get the customer to tell you what he/she really wants, design the software itself, implement and test it. You do not have to know each step in detail, but you should know a bit about them, so you can decide on what part of the software development process you really want to be specified: are you just a hacker, an architect, a system-engineer or are you working for QS?
So good luck,
Friday, June 29, 2007
When you start going to interviews you will get asked for code samples that you've written. Why not solve both problems and actually write some software. It doesn't have to be ground breaking, just something that solves a problem that you currently have (since you need domain knowledge).
You should provide the source code so that people can examine your coding style. It should also be free as this will make it more likely you'll get customers. This generates feedback and you can then build a version history following suggestions/comments. You then have a fabulous topic to discuss in an interview. You will be ahead of most of the competition as you'll be able to discuss dealing with customers and handling critisism as well as how to improve a product whilst maintaining an existing user base.
As an example, my sample application is ClipText (www.cliptext.co.uk)
Friday, June 29, 2007
Something I feel is often misunderstood by developers who have never lived through a complete product life cycle (and some who have), is the amount of time and work that still remains when the code is 'finished' to when the product is ready - testing, bugs, beta versions, changes, documentation, etc.
Writing code and producing a finished product are two very different things.
I would have liked to have a little bit of coverage of how to operate a command line debugger and how to manage a source code repository (as a user, not as administrator). In general, however, coverage of specific tools is not considered to be proper meat for a colege education. The fact that you list .NET as a central subject of your degree is, therefore, troubling: it indicates that this isn't a serious colege degree program, but more of a vocational program.
For most "real-world" software very little in the way of deep knowledge is required. Most software projects are little more than straight-line file/data processing, no more complex than a second year computer science homework assignment, only a little larger is scale. For this sort of work it doesn't take much knowledge, but it does take a fair amount of patience and attention to detail.
You need to be able to read and comprehend documents written by other people and write reasonably comprehensible documents yourself (though there is damn little competition from your peers on that score). If you can manage yourself well, organize and prioritize your work without too much oversight from you boss, you will go far as a developer, even if you don't know that much about the technical side of things.
Friday, June 29, 2007
"Therefor I'd like to ask what skills I should learn and practice to be able to develop real world software and what are the dependencies between those skills."
It depends on what kind of software you'd eventually like to write. Developing web sites is very different than developing flight control software for large aircraft.
The Software Engineering discipline suggests that every project should have the following attributes in common:
1) The requirements (or intentions) are specified in advance. The test criteria are also specified.
2) Progress is documented and tracked. (Check off requirements as you do them and write down how long it took.)
3) Once all the requirements are done, test your finished application against the requirements.
4) If further changes are needed, go back to step 1.
Keep in mind that this is overly simplified and does not take into account important subjects like configuration management. Which ones are relevant and to what degree will of course depend on what you're trying to accomplish.
I've always thought the hardest thing for recent college graduates to get used to was that you should NOT simply sit down and start writing code. In fact, many colleges do a poor job of teaching you to do steps 1 and 2 because the professors tend to do those steps for you.
Get into the habit of writing down what you want to do, why you want to that and how you plan to do it, before you actually start writing code. That alone is going to make you a much better developer. (Plus, you'll discover that you'll write better code faster.)
If you compare your finished project with your original plans, figure out why your original plans were wrong (when they are wrong) and learn from those mistakes, you're well on the way to being a prized software developer or project manager.
Friday, June 29, 2007
I'm not sure this is the exact question that was asked, but it kind of sounds like "I have a background in computer science/programming. What additional things I need to know to do software engineering?"
Look up the Software Engineering Body of Knowledge (SWEBOK) and the Software Engineering Institute's (SEI's) Capability Maturity Model (CMMI). Both of these are excellent resources, particularly if you ever have insomnia. However, boringness to the side, they take a broad view of "here are the different areas that you need to be good at to be a software engineer." You might try rating your knowledge of the different areas - None, took a class, did a project, etc. - and the ones you know absolutely nothing about, try to find books that specifically talk about them - testing, requirements, etc.
There are also some good general purpose books like Code Complete and Rapid Development that have an overview of different things that are useful to know and have extensive bibliographies.
"Writing code and producing a finished product are two very different things."
I agree strongly with this statement.
One reason most universities do not have any focus on this sort of thing is that almost no PhD level professors have ever shipped a product in their entire lives. They just work on toy problems, or combinatorics or graph theory proofs or the like. A contemporary CS department really does not know anything at all about product development, even if you add up the some total of all experience in the entire faculty.
Exceptions are rare. I can think of an adjunct professor I know who worked for a regular company and taught part time as a hobby. I also know professors who have successful products, but they are professors in the art department, or music, or psychology, never ever CS.
Saturday, June 30, 2007
The question is too broad to have a single, mining full answer, so I will try some alternatives, depending on how your question could be understood.
What I will definitely not recommend you is to spend too time in one single technology. By the time you finish mastering it, it will be obsolete. Also, there is not guarantee that you will find a job on that specific technology. Instead, try to broad your "computer literacy". That is, even if you are focused on .Net development, learn a little of java or C++. Take a look at how J2EE or Corba work. This way, you will have a richer perspective of any endeavor. This will result *invaluable* in you entire career.
If you are interested in the practical things that will help you in an job review, I think that UML and design patterns, are a must. I personally won't hire a developer that is not capable to "talk" UML and patterns. Even if your curse address these topics, I would recommend you to study them in depth, because there is a great different between getting the idea (which is simple) and really understand them.
If you are looking for something that differentiates you from the crowd, them look for some "exotic" but useful things that are very hot right now: functional programming, mobile computing or robotics. Putting that in your resume will be a eye catcher in some hight profile tech companies.
if you are wondering how to become a "real" developer capable to address real life challenges, then project management, software configuration and change management and testing is what you are looking for.
If you are interested in a mid to long term career path, I would then suggest you take a close look a broad software architecture topics, like enterprise application patterns, middleware, scalability, performance, security.
if you are interested in becoming a entrepreneur and create the "next big thing", then business planning is what you should consider first. Most good ideas dead early due to poor business plans.
Ah, and once you reach you dreams and become the next industry mogul (hey, Bill Gates didn't even get a grade), remember those who gave you wise advices one you were starting ;-)
Great advice in this thread.
One of the challenges of programming is how to get yourself "unstuck" from a problem. You have a piece of code that "should work fine", only when you run it, strange errors appear, and you just can't figure out why. You are stuck! What do you do? Well this is what I do, and I kind of organize it into four short little expressions, to try to make my code trouble-shooting advice a little less tedious to the programmers I coach :) Perhaps you might find it useful.
1) Check the cables first
2) Check your blind spots
3) Google it
4) Talk about it
Check the cables first! This is a reference to an early misadventure I had with a co-worker spending an hour trying to repair a driver for a network card on a computer that WASN'T EVEN PLUGGED INTO THE LAN. You are always trying to connect to something, some file, some database, some remote server, etc... Test that the connection works, the parameters are all correct. Programmers being "smart" people, we tend to look for the more interesting complex reasons first, but more often than not it is something simple that we missed.
Check your blind spots! When reviewing a problem in code, there are always sections that programmers tend to glaze over without really examining them - because they believe these sections to be "simple", "tested" and "working"... your mind tells you that the problem cannot lay there, but it so often is there, right in the simplest part of the method, or in the initialization.
Google it! If I am having problems with a new library or framework, weird errors I do not yet understand... I punch it in google, and look at results while I ponder the problem. So often I see younger programmers flailing away, running the same lines over and over again trying to wrap their brains around a "mysterious problem"... I walk over and google whatever it is they are having problems with and half the time, the answer, or at least a clue to the answer is a few clicks away. My reasoning is that someone, somewhere, has likely had this problem at least once and turned to a messageboard and asked a question, or sometimes I find an FAQ on some software site that uses the same technology, etc... In this way, your knowledge also grows from hearing of other's troubles with different aspects of programming.
Talk about it! - Post a question, talk to a co-worker. Oftentimes, in the act of preparing to describe the problem to another person, the essence of the problem becomes clear. The "Nevermind, I got it!" factor. If that fails to happen then there are all kinds of people who are glad to share their knowledge and experience dealing with such matters, on forums like this and newsgroups that target specific technologies.
I still code in Delphi
Tuesday, July 03, 2007
I'd like to thank you all for your advice.
I'm currently working (as a hobby) on a small mobile robot. It going to consist of an embedded linux board (Foxboard), USB harddisk, webcam, wireless network, motor driver board and several servos.
The software is going to be pretty extensive compared to previous projects. It's also going through unexplored territory.
This is what I want to achieve:
* Linux should be moved from the flash memory to the harddisk. The flash is going to contain a bootloader and the bare essentials, the rest should move to the harddisk. This is mostly to make it easier to modify the system.
* virtual memory: I want the board to use the harddisk as swapspace.
* PWM and servo signals generated by a deamon. This may be moved to an external microcontroller later.
* vision: I attempt to get the robot to move through a maze (black floor, white walls) and collect cola cans. This is the part I'm working on at the moment.
* Remote control in a webbrowser. The board already has an active webserver. I'd like to construct a webpage that allows the robot to be controlled remotely. I might add a videofeed from the webcam if resources permit.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz