Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've googled a lot and can't find what I look for.
I look for some architecture practice. I mean there are a lot of books about Design Patterns, but I want something like analysis of common mistakes in architecture of EE applications. All I've found - antipatterns like string concatenation or something else that can be found with help of FindBug or Sonar.
How I figure it out:
Book with next steps: task definition, wrong decision, why it is bad, right decision.
Educational resources. I heard there are such resources for testers. Some applications are opened for testing and each who want to learn testing can test it; and after some period discuss own result with other people or see the percent of bugs he has found.
Maybe other ideas?
Why I think Design Pattern books are not suitable for me:
A developer may know many design patterns from such books, but can be incapable of selecting the correct one for the specific situation. IMHO, this is because these books don't give you any practice, and fail to educate the reader as to which design pattern(s) should be applied to any situation. Those books just get you a ready solution.
EDIT:
There aren't any answers any more. So I want to expand my question:
I believe, no I'm certain that exist courses dedicated to improve architecture skills, show the common mistakes in designing of web applications and so on. Also I know that there are a lot of conferences linked with this subject.
Advice me where should I look for them, please.
Holub on Patterns is a fresh and interesting perspective on design patterns.
Lots of code. Lots of pro and cons, very hands-on and practical. I learn something new every time I re-read it.
It has been my go-to book as the "next step after GoF and Head-First Design Patterns". I love it, and it has been very well recieved by the ones who have tried it.
Can I assume that you know how to create independent objects using Dependency Injection? If not, this would be an excellent are in which to cultivate reuse and create a more robust architecture. Using DI would be an excellent way to re-architect an existing solution. (Contrast that with much evolved code, which becomes brittle because of interdependency.)
While you're not looking toward Design Pattern books, I'd ask you to glance at Refactoring to Patterns by J. Kerievsky.
Kerievsky takes you through some real-life refactorings which have titles like "Move Creation Knowledge to Factory." (It's "real-life" in that he uses actual code, not a contrived example.)
Finally, I have been encouraged in our recent use of Spring Integration as an Enterprise Integration Pattern. If you architect and implement even a modest project in Spring Integration, you'll get quite a lot of experience with both DI and EIP.
If you're writing enterprise applications, I'd recommend Patterns of of Enterprise Application Architecture when you're done with the basic design patterns.
It was written about ten years ago and some of the more modern things about how to shard tons of big data across cheap servers you will not find in there. The cloud did not exist when it was written. But it seriously discusses a lot of things that you won't find discussed elsewhere, and coins names / patterns for elemental building blocks of applications. I'd call it a classic rather than old.
See http://www.martinfowler.com/eaaCatalog/ for an index of the patterns that are discussed.
In my experience, the role of an architect is defined differently for different companies and often has less to do with code structure and patterns and more to do with your business requirements and practices. Employers seem to be more interested in what systems you might integrate into your solution or how you expect to interact with varous customers under conditions imposed by your company.
Correctly using a DI framework or design patern is something ever programmer should be able to without specific guidence from an architect, but researching and choosing which DI framework to use that might best fit your task is something an Architect might do.
They also tend to do more advanced impelementations--One of the better architects I worked with implemented the more difficult parts of our system, he wrote a custom Java classloader that loaded classes from a database and designed how it interacted with a GUI builder he designed so our customers could edit a GUI with Drag and Drop and we would save a .class file into the DB so it could instantly be loaded by all the client machines hooked to that server.
Some companies have different definitions than others--a company I worked with that did set-top cable box software had some architects that hardly programmed or had anything to do with software design, they were responsible for things like decomposing communication protocols and interacting with customers to help understand their problems (I viewed this more as Analyst work than Architect, but it was much more technical than most Analyst work I've encountered)
I guess I'm saying that an awful lot depends on the company you are working with. I suggest you go to your manager (or an existing Architect) and tell him you are interested in such a path and ask how you should progress.
When asked pretty much this question, one of the Architects I've worked with said that it's something you are always working at--you don't study up and finish, keeping up to date all the time on as much as you can is your new job--Where others might read a book or play a video game, you should be reading articles about software design, installing and playing with new software languages/tools/libraries and learning more about the specifics of your business.
In my views what I think going through the Class Diagrams of the Design pattern will help you a lot.
What more i will suggest is to take a brief of the Book "Head First Design Patterns". As per my experience this book has some very good example related to every Patterns which will help you in the pattern selection.
As per the selection of Design Pattern is concerned you can develop it by implementing more and more pattern in different scenario.
Take a look at Adam Bien's book
Real world java EE 6 Patterns
You can download an introduction based on this book at java.net
Real world java EE Patterns (pdf)
The first step is learning general good practices for developing applications. Knowing design patterns is very useful as it is a type of a language, so if you call something a "Controller" or "Request/Response" that automatically tells other developers the patterns you are applying and how to use it/work with it. Also, large software is typically built using them, so you have to know design patterns. Doesn't mean you need to squeeze every single one into every application, just saves you the trouble of solving problems others have already solved. As far as best practices at code level, Sonar is a good code analysis tool that taught me tons of do's and don't's.
Second, you need to narrow down the context and determine what types of applications are you planning on architecting. For example, web applications have different architecture from embedded applications, if you specialize in one you don't necessarily need to know all the ins and outs of the other.
Third, read up on Enterprise Integration Patterns.
Fourth, do hands on work with Apache Camel. It's a Java enterprise integration framework, great documentation and really easy to get up and running.
To me design patterns look like solutions to isolated problems. In real practice we have to deal with combinations of problems, which are highly dependent. I have never seen any pattern used purely. I can recommend one book which gives a wider view of software architecture: Domain-Driven Design: Tackling Complexity in the Heart of Software. It says how to approach to software design, instead of giving a set of common tools. With some examples it explains how to solve a set of problems in combination.
One more book gives an explanation on how to design classes and their collaboration: Interface Oriented Design: With Patterns. To write good understandable and maintainable code. It explains a lower level approaches rather then DDD.
My two cents :)
I agree with your observation that simply learning design pattern is of little consequence. A typical thing which generally occurs after learning design patterns is that the developer tries to map the a ready made solution (pattern) to a problem which is not the right way and will create more problems than what it solves.
IMHO, being an architect is more a matter of experience than academics. An architect is at core a Problem Solver or Solution Provider. By problems, I mean the large scale design problem and not the day today programming problems.
The problems could be from whether to use OR mapping tool or not to larger and more profound problems like whether to go for SOA or not and likewise. Its not about WHAT to do but HOW to do.
These things are a matter of experience. A problem can be solved by thousand different ways but while designing a system, due consideration should given to technical feasibility, performance, scalability, deployment, maintenance, extensiblility and many such non-functional requirements. Now unless you have been-there-done-that, its difficult get hold of these things which are very vital for today's software system .
Nobody can deny the importance of books(apologies for not introducing to new books as people here have already suggested wonderful books). They are written by very intelligent, sharp and most important experienced, people. I view this as a way of sharing once's experience and view point and they help you in chalking your path.
Apart from books, the other very important way to understand or learn about system design is ability to dissect the existing systems. For example, you might want to explore how a typical web server like Tomcat works or a DI framework like Spring works. Open source makes these things possible.
The best single way to be a great software architect, developer, or programmer is to work.
Get the basics down, and then work on something - especially something you are interested in. Hard work will pay dividends in the form of experience.
Surround yourself with people smarter than you, and listen to what they have to say. Trust that their experiences can help lead you into a better understanding.
Wisdom is not something that can be bought with a $50 book, or even a $100K college degree. Software craftmanship is something that you must earn.
If you have free time, working on a popular and successful open source project will help you gain great experience.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm in the process of putting together a year long PRACTICAL course (not academic) to produce Java programmers who can be productive from day 1. I've found that often computer science university graduates know all about the Fourier transformation, but as interesting as that may be, doesn't help me integrate them onto real life projects.
Apart from obvious programming I have thought of a number of other topics
Testing
Continuous integration
Source control
What to do if you have a problem (e.g. this site)
Agile and other methodologies
Documentation
If you can think of any others please let me know.
debugging techniques
The theory that's probably necessary:
How to sort an array with something that's not O(n^2)
The very basic data structures; array, list, tree, stack, queue, heap are the first to mind.
If not how to write them, then absolutely why you'd use a tree over a list over an array, or vice-versa.
The practical knowledge that's also necessary:
The book The Pragmatic Programmer covers most of what you're asking here.
Eclipse. How to work a debugger. How to work a profiler.
Ant.
Some basic web framework; Struts, Spring, etc.
Apache Commons, JAXB, a SOAP library, a REST library.
How to read bad, uncommented code. How to refactor it bit by bit to be maintainable.
What a good comment is.
HTML, CSS, JavaScript, JQuery, in that order.
Validators (W3C), formatters (Jalopy), checkers (PMD, FindBugs).
How to use a piece of Bug Tracking software; how to write a good bug description, how to explain what you've done to fix it, and how to handle user expectations.
Actually, that deserves it's own line; how to handle user expectations and conflicting timelines and goals.
You need to teach them how to:
Read other people's code for comprehension
Work within a legacy code base (the steps, from reading to building to running tests to modifying)
In addition to what you have, working in teams on a mid-size project. This will also (hopefully) help them see the benefits of source control, testing, and documentation.
Another answer mentioned debuggers. In the same respect, I would also give an overview of profilers.
One thing I wish my professors covered more in my programming courses was using IDEs effectively. My professors mentioned that we should check out Eclipse, but never really taught us how to use it to its full potential. Even now I frequently find new features of my frequently used IDEs that save me a LOT of time doing trivial tasks.
Once you get past the skillset needed to be a coder, I think the next step is learning to code smarter and not harder.
Code reviews.
Receiving and giving code reviews is not very easy and quite often people get annoyed quite easily, especially the one whose code is being reviewed. But it is very useful to be forced to take on criticism and to explain your decisions. For the reviewer it requires you to read other people's code and to be able to point out the problems in it and of course to describe why you think the developer has done something wrong.
I'd dedicate a fair chunk of time to UML and pseudocode design. Writing a quick spec or even a few lines of pseudocode takes some practice and has tons of benefits.
Another thing I'd recommend is build procedure. While this stuff varies from place to place, a primer on things like Ant, continuous integration, etc would be great.
Sounds like you want to teach software engineering more than Java. You have covered most of the main topics however, I would suggest the following as well:
Software Architecture: There is design and then there is architecture. Understanding how different components will/should interact in a project is important
Requirements gathering: Getting the actual spec from the "business owners" is a valuable skill. Too many people think that actual requirements for a project will just be given to them.
JDBC/Databases: You have to touch on databases if they are going to be useful on day 1.
MVC: I don't think it is important to go through all design patterns however, it is definitely worth mentioning MVC. It is an incredibly important pattern for Web development and really can be applied to most anything.
1 year is not a lot of time to turn someone into a software engineer. There is a lot of practical experience that has to be developed and generally speaking, that is why a Bachelors is 3-4 years.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I studied 2 courses in Java:
1- Introduction to programming with Java.
2- Data structures with Java.
In Both courses we used Java SE.
I loved it and I really want to be a great java programmer.
But, I discovered that I should know many technologies involved in Java software development:
Spring, Struts, JSP, JSF, GWT, Hibernate, apache tomcat and many more actually a lot more.
I hope it become simple process like .NET
you choose one language with one framework and IDE that is it.
Could anyone guide me to the best route or path to master Java, please?
What do you think about these two courses:
http://www.oreillyschool.com/certificates/java-programming.php
and
Advanced Java Certificate Series (from the same school, will be available in September).
I think most programmers have about average college graduate intelligence, including myself. What we do have a lot of though is patience.
That said, there are efficient ways to learn and inefficient ways to learn.
If you're stuck on one tutorial/book, try another book. Once you're done with the basics, there really is no "correct" order to learn.
Skim through the standard Java library documentation. Don't bother memorizing it, but be sure that you know the tools are there when you need them.
Make lots of test programs. If you're ever curious about something, try it out and see what happens. Don't know how big an int is? Write a program that prints out a sizeof. Don't know what happens when you call a virtual function of an override instance? Write a program with two classes, one inheriting the other, and try it out.
Read other people's code. Take note of style and structure. And I don't mean silly things like whether the { should go on the same line as the statement, but how they recycle variables, how they organize their classes, how they use loops, where they bother to optimize and where they don't etc. Emulate what you like.
Practice building "stub" programs -- you can do this in your head once you get the hang of it. Find your favorite program, and write out all the classes/methods as you think would have been used to build it. That'll help you with architecture.
Spend lots of time naming your classes. Don't use fancy names, just descriptive ones. It's a good mental exercise to think about names, even if you don't expect to ever share your code.
Try Project Euler if you're into that sort of nitty-gritty mathy stuff. I don't believe that programming is all about math, but you might like it.
Learn C sometime. C++ probably isn't worth it if you're doing java, but C will teach you how your computer works. You don't need to master it, but at least get to the point where you understand memory management and pointers. That'll help you make decisions faster when you want your code to be really fast.
Learn functional programming someday. Haskell's a good choice, because it's a pure functional language. It's extremely difficult at first, but the concepts you learn from it are valuable regardless of what language you program in. You'll be making design decisions a lot faster, and your code will be a lot more robust.
Keep up to date. Trends come and go in this industry as fast as in the fashion industry. A lot of it is crap, but a lot of it is crucial both to employment and productivity. Always keep an eye out, or you'll go the way of the dinosaurs.
The best way to become good at something? Practice, practice, practice.
Don't focus on a single framework just do lots of Java, take a look around open-source projects, find something that needs fixing or implementing and do it or think of something that you want but doesn't exist and make it.
Practice doesn't make perfect - perfect practice makes perfect. If you continue to make the same mistakes, you'll only succeed in developing bad habits.
You need to read this.
Your Java roadmap ought to look like this:
Concentrate on core Java JDK classes to start. Don't worry about Java EE until you're comfortable with interfaces, classes, and the basics. JDBC is an important part of core Java, so be fluent with it. You'll have to know about relational databases, normalization, and SQL. GUI technology here is Swing.
Once you have that, take up servlets, JSPs written using JSTL exclusively (no scriptlets), and JDBC. You'll have to understand something about Tomcat (or another servlet/JSP engine), HTTP, HTML, CSS, and a little JavaScript as well. You can go a very long way with just these.
Once you've mastered 1 and 2, you'll have to make a choice of framework. I'd recommend either swallowing Spring or EJB 3 whole. I'd recommend Spring first, but I'll admit that I don't know EJB 3 well.
I get the impression from the phrasing of your question that Java is your first programming language. I laud your desire to "master Java", but if I might, I'd like to suggest that you try a little breadth before you get too much depth!
It's easy, I think, with a CS degree where most courses are taught in Java, to fall into the trap of believing that all programming languages are:
object-oriented (and with single implementation inheritance and multiple interface inheritance)
statically-typed (with no type-inference)
imperative (i.e. making use of iteration constructs and mutable state)
verbose
and therefore that all programming must look roughly like Java programming.
I'd humbly suggest doing some reading on different paradigms and languages: learn a dynamically typed language (coming from Java, I'd suggest Python or Ruby), learn a non-OO language (like C)---and implement OO, learn about functional programming (Haskell's a great eye-opener). At least take a look around before diving head-first into Java alphabet soup (Java culture highly values acronyms---but I'll pass no value judgments on this here).
Just my US $0.02!
Write programs in it. Find open source programs that use it and fix their bugs and add functionality to them. The best way to get experience is to experience it.
If you really want to know what you should be studying, within the realm of your examples (Spring, Struts, JSP, JSF, GWT, Hibernate, apache tomcat), then find some podcasts and blog posts that allow you to survey these technologies. You can then choose the ones you are most interested in for further study.
I agree with the other two respondents (practice, particularly with open-source projects, is the best way to get good at a language). However, I wanted to add one thing. It's unclear from your answer how much experience you have with object-oriented design, and with Java, that's essential. I'd recommend looking into advanced OO design to get a sense for what's out there. My favorite book on OO design is available for free and linked below - see if it's at your level. If not, find something more/less advanced and work from it.
http://homepage.mac.com/s_lott/books/oodesign/build-java/html/index.html
Java Technologies are very vast, from mobile phones, to enterprise level servers. You might want to first narrow what you want to learn.
Your first talk about Java SE(applications programming) and then start mixing in Java J2EE, and Java EJB.
If you want to go down the web route or enterprise server then you need to learn J2EE,EJB,Hibernate,Spring,etc otherwise these technologies aren't seen as often when programming applications.
It still seems like you have a long road to go, probably the most beneficial for you to learn next would be Java Swing(gui).
Practice and learn frameworks as you need them (or come across them). There are way too many frameworks out there (for Java and for .NET) to learn in one shot.
Learning the standard Java class libraries is always a start
The best way to become good at something? Get a job that allows you to use that technology. Get paid while practicing.
There is a time to stop reading books and articles, and get to work building a project.
As you are working, learn from others who are better than you. Continue to read articles on topics that interest you, and apply what you learn at work.
Find a mentor and pick his/her brains often. Once you are working in the field ask for code reviews from senior developers. This will get you out of your own habits, and reading people's suggestions for how you can improve will give you plenty of insights. Don't sit around reading, solve problems on a per-problem basis and work your way up from there.
Its not that easy to became a master in Java, what i have done to study java is
1)try to convert all the apps i have seen into java,
eg:paint to java
2)used to went to JAVA user groups and conference in my state
3)Went to Groups in Goolge for checking Codes of Java
thats all i do, i cant say i am the master, but i am able to do the stuff
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I have been programming in Java for the past 2 years and now i want to get into Designing applications. So far i am only into coding ie; i am given design document/class diagram etc and asked to code. Now i want to learn how to design, i mean i want to lean when should a class be interface not a concrete class, coming up with design given the requirements , design techniqies and all the other aspects of desiging.
To learn all these could you plese suggest any series of articles/books etc.
I have tried reading Headfirst Design Patterns, but even though i am able to grasp few design patterns, i am still not able to get on to the desiging apllications on my own.
Please help.
Design Patterns are quite advanced examples of design features built on fundamental principles such a Separation of Concerns, Coherence and Extensibility. If you are at the stage of wondering about Interfaces and Classes you may need to do some reading about fundamental OO ideas. For example read about SOLID principles. So I would not fisrt buy a book, I would start at that article and follow links and googles from there.
Then, reading is not enough, you need to do.
Next time you get a spec, study it. Understand the problem that is being solved, then go home and design it yourself. Compare your attempt with the spec. Or consider alternatives to the spec you are given, suppose you didn't have an interface here, or a Factory there why would this matter?
Ideally, your growth would be enabled if you leaders would start to give you less specified problems and allow you to design them. Project pressures may prevent that. In which case I think you need to do work in your own time. Pick some small projects and work on them. This may be tough unless you have mentors, but I think reading without doing is not going to advance you so quickly.
This is a common question, and I don't blame you for asking it! It's something that we all ponder. You may find this question, and the associated answers, useful:
Learning/Implementing Design Patterns (For Newbies)
You might read Effective Java by Josh Bloch.
Design patterns are good, definitely read up about them, but it is knowing when to use them that is the real skill. Mostly you need to get your hands dirty.
A mediocre coder will be given a task, bang on the keyboard until they have something that works, and move on. Occasionally just getting something working is the right thing to do, but often a coder like this leaves a swath of horrible code in their wake.
You can learn an enormous amount from taking a more academic approach. Write some code, get it working, then improve it. Rewrite it from scratch reusing what you have learned writing it the first time. Spend extra time looking at what you can improve regarding all aspects of the code: speed, memory, algorithms, design patterns, even your coding style.
For the beginning try this:
Read a paragraph about 1 design pattern (as they listed in the book).
Try to understand the problem it solves.
Imagine some task with this problem.
Code it.
Draw a class diagram of your program on a piece of paper (without automated tools).
One pattern per day will be a very good velocity.
The only way to improve is to read design patterns, try stuff, learn from mistakes, and get advice from people who have some of this experience already. Another thing is you should know when not to use patterns also. some times we overlook by design patterns and it spoils the project.
I agree with Ben, and would like to add my 2 bobs worth...
Design is an art, and like painting it doesn't come from books, it comes from inside.
Concepts like Design Patterns are not the alpha and omega of design, they are part of the toolkit used to create a design. Design Patterns in particular give us a vocabulary for describing approaches to solving some common problems. However identifying the problems to solve is part of the art of creating a design from requirements.
Have a look at the requirements that relate to the design documents you receive to code with. Think about the way that the designers have broken the requirements down into a series of finite problems to solve.
And of course, don't be afraid to ask your designers about their approach.
Best way to learn something is to learn by doing and learning from other real world projects.
Learning design patterns is essential to design good applications but that alone will not be sufficient. Apart from books/reading/examples I recommend going through the design of existing applications. Choose an Open source project - explore, experiment and contribute to the project. While contributing learn about the design principles and methods used in the project. Don't be afraid to try multiple projects until you find the "one" which excites you the most.
Ofcourse initially you will need theoretical knowledge to begin with, so I recommend the following book:
Applying UML & Patterns by Larman
Designing applications takes a bit of practice, but that shouldn't stop you from trying. After a while, you'll get the hang of it;
A tip: Try to learn from your colleagues. Let them show you how they design applications, what process do they follow, how do they identify problems and do they use patterns to solve them? Sometimes it's best to see how the design process works instead of trying do learn it all by yourself.
My 50 cents on good resources:
SourceMaking Design Patterns
Video course on design patterns
My question is broader than merely expanding language specific skills. I'm wondering what sort of advice anyone might offer to someone with a desire for knowledge, but a lack of direction. Feel free to skip down to the question.
Background: I've taken a single computer science course in java at my University, but i'm planning on majoring in Computer Science and Electrical Computer Engineering (ECE). My java class was quite rudimentary. We were provided with a framework and merely edited/created a few methods and classes to perform a simple task. We made a version of Breakout, and created an AI for a simple connect-four game. Although I'm somewhat familiar with big O notation, I haven't actually studied it in class (My next CS class covers this). In my introductory ECE course we also programmed BOE-Bots in PBASIC to compete in an obstacle course of sorts. As an engineering student, I was also introduced to matlab, although I've only used it for linear algebra homework. In summary, I don't have much programming background, but I've loved pretty much everything I've done so far, and I'm looking for ways to build a more valuable skill set.
Steps Taken: After paying more attention to the programming section of reddit, I found a link to Project Euler. This summer I've been hacking away at those problems (finished my 42nd solution yesterday), but I'm looking for some more direction. I've been reading blog entries and SO heavily. I'd like to learn something about php, and perhaps create a dynamic webpage, but fundamentally I want to do anything in my power do to improve myself and prepare for the working world.
Question: What would direction would you recommend for me? Should I learn a new language? Keep attacking Project Euler? Read some books on programming? Start a coding project(I wouldn't even know where to begin)? Wait until school? Learn about more fundamental programming principles?
I guess with all the paths available, I'm just a little overwhelmed, and I don't want to fall into a path that might be detrimental to my career opportunities. I'm also really bad at making decisions. Your advice would be greatly appreciated!
The word quickly worries me... I suggest you read Teach Yourself Programming in Ten Years - Why is everyone in such a rush?
~~ Peter Norvig
Forgive yourself if you're not setting the world on fire three weeks after sitting down at the keyboard... maybe you're destined to be a late bloomer?
;-)
Most everyone is suggesting doing more programming. Whilst that's obviously important, I think it's important to understand the environments that your programs work in.
I would investigate how operating system work (how they allocate resources for you, how they schedule programs and threads), how networks work (routing, TCP/UDP behaviours and limitations etc.), and some database theory.
I see a lot of junior programmers with great language knowledge, but beyond the sandbox of their program they don't have a clue how the computer/network enables their stuff to run.
Knowing something of the above will make you a better programmer in terms of how you write your programs, and how you understand how they'll work (and indeed, how to debug them or analyse their failures)
There is only one thing that can improve your skills as a programmer: Program.
Reading books about programming is akin to reading books about cycling. It's not going to turn you into a cyclist.
Program something that you'll use and have a vested interest in. Then just put your head down and do it - reading any supporting information as you go.
Programming skills are just a small part of what makes a successful programmer, IMHO. Being able to read specifications, ask questions and interact with other people to extract the information you need to program are very important too. Pay attention to your 'soft' skills, they will help you a lot in being a successful programmer in a commercial setting.
I'd reccomend you take a multi-pronged approach. Reading books can only take you so far, since they don't provide you with practical experience in developing an application from scratch. Programming is much more now about writing code; you have to be able to design applications, read documentation, and know how to solve the needs of a customer who doesn't know how to tell you what to write.
If you're still in college, try to find an internship with a development firm. You'll get access to people and resources who already have this experience. If you for some reason can't do an internship, find and make a friend who is a developer. The impact of having someone who knows what they're doing to bounce ideas off of is immeasurable.
In addition to surrounding yourself with people with knowledge, you should also take on writing an application all your own. Pick something that interests you, but at the same time try not to make it too complicated, you don't want to frustrate yourself by writing a boring application, or choosing something that has too steep of a learning curve. Remember that the application is at it's core, a tool to assist you in learning, so it's OK if it turns out to be less complex then you imagined, or if the code you're practicing doesn't apply within the scope of what you're trying to write.
You definitely need to write code in order to become a better programmer. If you don't have a particular idea for a program to write, pick an open-source program (ideally one that you use), contact them and find out what they need done; contribute something. Fix a bug, implement a feature... start small and work your way up. This will help you learn about working on a team, writing maintainable code, preventing problems, and working on useful tasks. Much of what people write while learning to program is just exercise code, and not actually useful or representative of anything realistic. That is why a real, useful program is the best thing to do.
I saw an interesting link for a site called CodeKata that might help you. The important thing to get your skills going quickly is to actually code for practical problems that you will be likely to encounter in any real job.
Besides picking an interesting project and implementing it from scratch, reading others' code can also be valuable in improving your skills. Scott Hanselman has a good series on reading code: Weekly Source Code
Since you already know the fundamentals of programming, and obviously have the desire to learn I would start a pet project.
Nothing has forced me to learn great deals about a technology, language or idea more than having a fairly challenging pet project to throw my self into.
I would recommend, like rein mentioned, picking a project you really have a true interest in. Other wise it will get boring pretty fast and you'll have no idea why you are working on it. I think it would be wise to make the project fairly non-trivial. I always found the less trivial a project I was working on, the more I learned and took away from it.
Also If you live near a college/university research labs on campus are pretty much always looking for summer interns to work on code in one shape or form. Some will even pay you. I did this for 4-5 years through high school and some university and it was a great learning experience.
Obviously participating in an open source project is a great way to gain experience at working with other developers. Check out stuff on github, sourceforge, bitbucket.
I'd only caution you to ask for help and bother the core developers of a project you are very interested in and you are going to stick with. Generally open source developers dedicated to there project are few and far between. Their time is really valuable to the community and to waste it on someone who is just going to fly by night and never be seen again is kind of a shame.
It sounds like you are writing programs happily, and are a decent java programmer. So writing more might not be your most productive way of learning new things.
As a result, I'd say learn a new language - knowing more than 1 always exposes you to new concepts. As a java programmer I'd suggest C/C++ as they've immensely popular but they fill areas that the 'managed high level' languages don't go, the low-level high-performance, to-the-metal applications. If you learn C# (for example) you'll find you're just doing a different dialect of java (roughly) and you won't learn too much.
If you don't like the idea of C/C++, get into a scripting language instead - bash, VBScript/WMI, or perl or python. they'll be sufficiently different to teach you some good stuff.
Or do both!
You already know how to program; in order to prepare yourself for a real life job, the most important thing is probably not how to program better, but to learn the things you'll have to do that aren't programming.
In your workplace, you most likely won't be asked to write line "fire and forget" programs, but work in a team on large applications. In order to do that effectively, you need to learn:
How to communicate effectively with analysts, customers, managers and your fellow programmers
How to plan and coordinate work: using source control systems and bug tracking systems, working with written specifications, following a development process - "software engineering"
Perhaps most importantly: get used to working with other people's code - third party libraries, frameworks, and of course colleagues' code.
This, too, can most effectively be learned through hands-on experience in a real project. For me, the big eye-opener was working in a group of about 10 students in an experimental project organized by university with some industry support. Perhaps you can find or organize something similar at your university? If it has a chair dealing with software engineering, they should be happy to do something like that if they aren't already. Failing that, joining an open source project is good too.
Write programs to automate things that you do manually on a daily basis.
Like, todo lists, keeping accounts, checking RSS feeds.. the list could be endless. If you do some business on the side, write some simple code to assist you in that.
The essence is: to improve your programming, do programing! :D
Contributing to open source projects has a surprisingly high impact on your ability to develop software, as opposed to the ability of writing code:
you get to work on code written by others, which is sometimes brilliant and sometimes abysmal;
collaborate within a geographically distributed team;
get introduced to team politics ( yay! );
understand what it means to have actual users.
to quote just a few. Some good places to look:
Codehaus
Sourceforge
Google code
Find out about best practices (for example training videos on windowsclient.net). Get any problem and solve it using database as input and database as output. Start over several times. That's as close as you can get to the real world scenario. Read books recommended by Joel.
Here's my multi-prong suggestion:
1) Big picture work - Look at various Software Development methodologies and see how when you program you follow one of these approaches. You did some Java work, was that web, windows application, console application, or something else? Learning a little about the other types may also prove useful
2) Medium picture work - Have you looked at Refactoring and Design Patterns? These can be very useful but may require a bit more coding experience to see how they can be useful.
3) Small picture work - Study various algorithms and understand various trade offs one can make in choosing various implementations of a data structure, e.g. linked lists vs. arrays. There is a big white book about Algorithms that some use when studying them.
My multi-advise:
Keep training, and write code. Participate in small open source project.
Read standard book (here is the Jeff's list)
Learn from your mistakes, or better from the mistakes of others by reading site like www.badprogramming.com
From 99 ways to become a better developer:
Program! and try to diversify your work as much as possible
Find a mentor
Be a mentor
Learn about the different aspect of software development other than code (business of software etc.)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
It's been mentioned to me that I'll be the sole developer behind a large new system. Among other things I'll be designing a UI and database schema.
I'm sure I'll receive some guidance, but I'd like to be able to knock their socks off. What can I do in the meantime to prepare, and what will I need to keep in mind when I sit down at my computer with the spec?
A few things to keep in mind: I'm a college student at my first real programming job. I'll be using Java. We already have SCM set up with automated testing, etc...so tools are not an issue.
Do you know much about OOP? If so, look into Spring and Hibernate to keep your implementation clean and orthogonal. If you get that, you should find TDD a good way to keep your design compact and lean, especially since you have "automated testing" up and running.
UPDATE:
Looking at the first slew of answers, I couldn't disagree more. Particularly in the Java space, you should find plenty of mentors/resources on working out your application with Objects, not a database-centric approach. Database design is typically the first step for Microsoft folks (which I do daily, but am in a recovery program, er, Alt.Net). If you keep the focus on what you need to deliver to a customer and let your ORM figure out how to persist your objects, your design should be better.
This sounds very much like my first job. Straight out of university, I was asked to design the database and business logic layer, while other people would take care of the UI. Meanwhile the boss was looking over my shoulder, unwilling to let go of what used to be his baby and was now mine, and poking his finger in it. Three years later, developers were fleeing the company and we were still X months away from actually selling anything.
The big mistake was in being too ambitious. If this is your first job, you will make mistakes and you will need to change how things work long after you've written them. We had all sorts of features that made the system more complicated than it needed to be, both on the database level and in the API that it presented to other developers. In the end, the whole thing was just far too complicated to support all at once and just died.
So my advice:
If you're not sure about taking on such a big job single-handed, don't. Tell your employers, and get them to find or hire somebody for you to work with who can help you out. If people need to be added to the project, then it should be done near the start rather than after stuff starts going wrong.
Think very carefully about what the product is for, and to boil it down to the simplest set of requirements you can think of. If the people giving you the spec aren't technical, try to see past what they've written to what will actually work and make money. Talk to customers and salespeople, and understand the market.
There's no shame in admitting you're wrong. If it turns out that the entire system needs to be rewritten, because you made some mistake in your first version, then it's better to admit this as soon as possible so you can get to it. Correspondingly, don't try to make an architecture that can anticipate every possible contingency in your first version, because you don't know what every contingency is and will just get it wrong. Write once with an eye to throwing away and starting again - you may not have to, the first version may be fine, but admit it if you do.
I also disagree about starting with the database. The DB is simply an artifact of how your business objects are persisted. I don't know of an equivalent in Java, but .Net has stellar tools such as SubSonic that allow your DB design to stay fluid as you iterate through your business objects design. I'd say first and foremost (even before deciding on what technologies to introduce) focus on the process and identify your nouns and verbs ... then build out from those abstractions. Hey, it really does work in the "real world", just like OOP 101 taught you!
Before you start coding, plan out your database schema - everything else will flow from that. Getting the database reasonably correct early on will save you time and headaches later.
The main thing is being able to abstract the complexity of the system so that you don't get bogged down by it as soon as you start off.
First read the spec like a story (skimming through it). Don't stop at every requirement to analyze it right there and then. This will allow you to get an overall picture of the system without too many details. At this point you would start identifying the major functional components of the system. Start putting these down (use a mindmap tool if you like).
Then take each component and start exploding it (and tying each detail with requirements in the spec document). Do this for all components, till you have covered all requirements.
Now, you should start looking at relationships between the components, and whether there are repetitions of features or functions across the various components (which you can then pull out to create utility components, or such). Around now, you would have a good detailed map of your requirements in your mind.
NOW, you should think of designing the database, ER diagrams, Class Design, DFDs, deployment, etc.
The problem with doing the last step first is that you can get bogged down in the complexity of your system without really gaining an overall understanding in the first place.
I do it the other way around. I find that doing it database-schema-first gets the system stuck in a data-driven-design that is difficult to abstract from persistence. We try to do domain model designs first and then base the database schema on those.
And then there's the infrastructure design: the team should settle on conventions on how to structure the program first and foremost. And then we work together to agree first on a design for the common functionality of the system (e.g., things everyone needs like persistence, logging, etc.). This becomes the framework of the system.
We all work on that together first before we split the rest of the functionalities amongst ourselves.
It has been my experience that Java applications (.NET also) that consider the database last are highly likely to perform poorly when placed into a corporate environment. You need to really think about your audience. You didn't say if it was a web app or not. Either way the infrastructure that you are implementing on is important when considering how you handle your data.
No matter what methodology you consider, how you get and save your data and it's impact on performance should be right up there as one of your #1 priorities.
I'd suggest thinking about how this application will be used. How will future users work with it? I'm sure you know at least a few things about what this application needs to handle, but my first advice is "think of the user and what he or she needs".
Draw it up on plain paper, thinking of where to section off the code. Remeber not to mix logic with GUI code (common error). This way you will be set to extend your applications reach in the future to servlets and/or applets or whatever platform comes along. Section in layers so that you can respond to large changes faster without rebuilding everything. Layers should not see any other layers than their closest neighbouring layers.
Begin with true core functionallity. All that time consuming fluff (that will make your project 4 weeks late), wont matter much to the wast majority of users. It can be added later once you are sure you can deliver on time.
Btw. Even though this has nothing to do with design I'd just like to say that you won't deliver on time. Make a realistic estimate on time consumption and then double it :-) I assume here that you will not be alone in this project and that people will come and go as the project progresses. You may need to train people midway through the project, people go on holiday / need surgery etc.
Split the big system to smaller pieces.
And don't think that it's so complex, because it usually isn't. By thinking too complex it just ruins your thoughts and eventually the design. Some point you just realize that you could do the same thing easier, and then you redesign it.
Atleast this has been my major mistake in designing.
Keep it simple!
I found very insightful ideas about starting a new large project, based on
common good practices
Test Driven Development
and pragmatic approach
in the book Growing Object-Oriented Software, Guided by Tests.
It is still under development, but first 3 chapters may be what You are looking for and IMHO worth reading.