Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
As a student I have many languages/technologies to learn. Many times I forget past languages within 2-3 years unless I am practicing them on a regular basis.
Suppose on a later date, you have to remember it again. You have to almost start from basic & revise it. Isn't there a better way to retain all the things I learnt?
Live Example: As a student I have to learn C++, JS, Vbscript, Bash, and later on Java and C#/.NET. My side projects are also in PHP.
All these are different in their syntaxes, number of features & quirky inner details.
Especially in C++ & Java there are so many inner details that must be remembered. Like initialising base class pointers with derived class object, different ways of casting in C++, and so many more that are so different from any other language.
Forgetting all this in 2 years is just a huge loss.
How do you remember all these different languages and technologies?
P.S: I had one idea of a quick reference sheet. Does anyone have any experience of creating one? Is there any place where I can get them? What are the other ideas?
It's all repetition really. You'll be doing a lot of it and you'll eventually get used to it. Languages that are very similar, like Java and C#, can be a bit confusing at times, but that's where code-completion comes in handy.
You'll get used to it eventually. And every programmer who has to work with many different languages always needs to refresh him/herself after not doing a particular language in a while. There are no exceptions there.
Don't be put off by tutorials you find online, or blogs with loads of examples. The people that post those work several days, maybe even weeks on a single post. They're not super-geniuses who sit down, write their article in 30 minute and post it. Much preparation goes in to those things. In fact, most blogs that have a high turnout, have multiple people working on it. But their names are always in tiny print somewhere at the top or bottom so I always missed that. I know I used to assume these people were just that talented that they could come up with a big idea and write it out in a couple of hours. And many people who were in college with me also thought this. It all seemed so grand and frankly, it was a bit depressing. The idea that we would one day become that good seemed so far away that many people I knew in college just gave up.
Don't be put off by the magnitude of it all. You'll get used to it if you do it enough. Don't pay attention to those books you see in stores or online that say "Java expert in 24 hours". Realistically speaking, count on 5-7 years to become good at a certain language.
Googling "Java Cheat Sheet" and "C++ Cheat Sheet" will turn up some pretty good ones as a starting point. Making your own is a better option though, improve on it as you go and you'll come out with something you're familiar with and excludes things you don't need.
Over time you'll probably get over this problem but a quick reference sheet never hurts.
Get Cheat sheets of each programming language or libraries
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 6 years ago.
Improve this question
I have a project which requires some complicated components built. Some of these components are promised by some obscure software packages which are proving to be poorly documented and difficult to configure and use.
I am wondering where other people draw the line during their software research phase in deciding whether to build their own packages or sticking with trying the existing packages?
And what percentage of the total project time should I spend on this kind of research?
Thanks in advance,
Alex
Ask yourself which is likely to take longer, hammering the components to fit your needs or writing your own.
Personally I pretty much always use solid, comprehensive libraries (jQuery for web development, DevExpress for WinForms) and fill in the gaps with my own code.
The only exception I remember off the top of my head was a tooltip plugin for a web application. I tried like 3, wasting hours and hours adapting each of them to my needs, even modifying their source code, playing with their images, fixing obscure css tags that baffle ie7 (cause ie8 defaults in ie7 mode on the intranet), but never quite getting it right, then just gave up and rolled my own in half an hour.
Not to say there aren't plenty of good components out there that are flexible enough to be used in active development environments, but you're unlikely to find them in the heat of developing your stuff with deadlines looming overhead. Use your free-ish time to look for them and bookmark them, try them out in a few toy projects and see how they work, so the next time you need something like them you know what to use.
If you have to fix some minor bugs or otherwise have to observe some patterns the code doesn't currently take into account, consider contributing back into the code base as a good citizen.
If you find yourself having to substantially recode some pre-provided code to get it to work, then maybe the fact it was already "coded" is irrelevant. Bite down and chew.
If it's bologna and you need to reinvent the "wheel", consider that you've got a job that may not be compensating it's actual value.
I usually draw the line at about 1/10. Meaning if it has already taken me, say, 1 day and I still haven't gotten the off-the-shelf thing working and it would only take me 10 days to do it myself, I do it myself.
Even when it takes a little longer, it's often better in the long run to avoid the complicated, hard-to-use thing. Or, at the very least, I get a better idea of what I really need and I can pick an off-the-shelf package with my eyes wider open.
Well i think it all depends.
Given that, it is possible for you to spend more time than u would have used for development at trying to configure and understand. I would say if you are good enough to create faster than learn the improperly documented on then go for it.
Else if the existing promises great features and will not take too much of the entire project time then go for it. Often it is very difficult to draw then line. It all depends on the situation at hand.
Also you could look for alternatives to what u have now.
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 3 years ago.
Improve this question
I have worked on a few multi-cultural projects (programming languages are universal, social norms and mores are not) and it's always interesting to see how the team dynamic works cross culturally. I'm not talking about coding differences, I'm talking about basic ground rules for communicating cross culturally at the start of the project. Good team building exercises, using small teams vs large teams, isolating functionality to make all developers feel as if they are contributing, fostering respect, and etc.
In our increasingly multi-cultural industry, what works and what has failed?
I looked into this in some detail a few years ago and came to the following conclusions (in no particular order):
The outsourcing organisations we looked at (all Indian) had a very strong process base. I don't know if this was cultural or just the way they chose to set themselves up (possibly a bit of both) but we felt this was likely to be a real issue.
They were talking about being a five on the Carnegie Melon Maturity Model (Google it but basically that means they've defined and documented everything up to and including what happens when someone farts), we were typically running around a 1 or a 2 (roughly equating to crossing your fingers and hoping for the best).
Our process level was largely driven by our clients who didn't have any interest in signing off specifications (for good reasons and bad), wanted people who understood their business and would fill in the gaps, and wanted to change their minds three times a day. As much as many of these factors infuriated the programmers in the UK we understood that they were never going to change.
This was possibly our biggest concern - we didn't feel we could come up with a process model that would work for all three groups involved (the clients, the UK based IT team and the Indian based outsource team).
So first thing is - work out what your process is and work out whether you honestly think you can make it work for all parties involved. It's easy to say "we're going to do agile" but how are you going to get that to work when one party is 1000 miles away? Alternatively if you want to go a solid waterfall route, is that realistic given your clients?
Second, understand the ingrained cultural differences within your teams.
My experience (and I obviously generalise here) is that programmers from the US and the UK willingly (sometimes too willingly) question authority and assumptions. Ask them to do something dumb and you're likely to find yourself being told that you've asked them to do something dumb in no uncertain terms and they'll then proceed to tell you what you really want.
That's not the norm globally. Many Indian developers I've worked with don't question things in the same way. That's not to say they aren't as bright, they just apply their intelligence to delivering what you've asked for, assuming that you had a good reason for doing so.
You can make a case for either of these being good / bad (I've lost count of the number of times I've heard developers question what they're told and say how things should be despite not understanding the basics of the industry they were working in), but the important thing is that they're different and they'll clash.
So the answer is likely to be that you're going to need to feel out the teams involved and, based on that, pick out ways of working that are comfortable for both of them.
Yes, get video conferencing set up, get each time to visit the other site (it makes a big difference) and where possible get people talking even when it's not strictly needed in the early stages, but most of all make the effort to understand the groups involved and design a dynamic that works for all of them - imposition of one world view on the other won't work.
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 3 years ago.
Improve this question
Our profession often requires deep learning; sitting down and reading, and understanding. I'm currently undergoing an exam period, and I'm looking for ways to learn more effectively.
I'm not asking about what to learn, or whether to prefer blogs over books, etc. My question is much more physical than that -
What do you do when need to study, and I mean study hard?
I'm looking for answers such as
I slice my time to 2.5 hours intervals and make a break between them, but never during.
I keep a jar of water nearby.
I wake up at 6 o'clock sharp and start my day with a session at the gym.
What good learning habits did acquire, or wish you had acquired?
(I know this isn't strictly programming related, but it is programmers related)
I find the best way to set yourself up for learning is:
Get plenty of exercise and rest
Eat a balanced diet with little sugar and caffeine
Try to find a quiet area conducive to concentration
Try to practice what you learn from a book - theory is ok, but practice embeds the knowledge.
"The best way to test whether or not you know something is to try to explain it to someone else from scratch."
That has to be one of the best ideas I was ever given about knowing whether or not I really know something.
Make sure it's quiet and comfortable around you.
enough to drink and eat
don't just read but take notes, draw mindmaps and the like
don't just read but try
make a report, blog entry, presentation out of what you learned
learn the same thing from different sources: Don't just believe what person A has to say look for, read and understand the opinion of person B and C as well and understand the differences.
take nothing for granted
apply the knowledge to an actual project
I set aside time every day or x times per week. Otherwise I never do it.
I try to have a diff location every once and awhile (home / coffee shop / stay late at the office) keeps the tedium away.
I am careful about the music I use, try to make sure it is relaxing
Sometimes I leave headphones on even if music is off that way people don't talk to me.
I give myself specific goals before each break or for every session.
I reward myself
Read Andy Hunt's "Pragmatic Thinking and Learning" - lots of good suggestions there.
Tony Buzan wrote The Mind Map Book, describing his ideas for note taking. He also has some process ideas that I found very helpful. Foremost was this one: study new material for an hour, then take a short break (5-10 minutes) and then review the new material. Review the new material again an hour later, then two hours after that, then the next day. You need to refresh your exposure to the material multiple times over the course of time to really take it in.
While reading, I make sure I fully comprehend each section in the text before I continue.
Set up a time and take away all distractions. At home/dorm can be rough, so I would use the library while in college. Getting started is usually the hardest part, so don't set a specific time limit for when to quit. It is distracting, and you will be looking at your clock to see "how much longer you have." You don't want to be in that mindset. Work until you feel your brain is starting to lose focus, whether that is lack of comprehension or having to reread simple paragraphs repeatedly. Take a minute or two as a break, then refocus your mind. When that stops working, it is time for a real break.
Are you a night owl or early bird? Each person is different. I am very productive early in the morning, while my wife can barely function. We all have differences, so don't try to fight your nature.
+1 to what everyone else said. Making cheat sheet/notes were a very important part of my studying habits, whether I could use them on the exam or not.
I find it best to be fully dedicated to the task before I start. If you go into something with low morale, you will not do well. If you go into a task with high morale, you will understand things quicker, be able to apply it to real situations better, and will have a deeper comprehension. If I am not fully dedicated, I don't even bother. I've got better things to do with my time then half ass something, and you probably do too.
Expanding on a comment I left, see this article from Electronic Design from a few years ago: http://electronicdesign.com/Articles/Index.cfm?AD=1&ArticleID=5859.
If you can teach what you learned, you know it.
by Louis Frenzel
All learning is self-learning. Professors, trainers, and all teachers just organize and present the material to be learned. They don't teach it to you. You learn it. You're the one who actually absorbs, understands, and assimilates the knowledge by listening to the lectures, reading, thinking, solving problems, and other activities. Self-learning is a natural, human quality. While most of you have used this method in the past, you may want to do it on a more formal basis to speed up and fine-tune your methods. Here's a suggested approach (and trust me on this, you must write it down):
Clearly identify what you want to learn. Write it out.
Write some learning objectives for yourself. These statements clearly identify what you want to know and be able to do. For example, you should write something like "When I complete this learning assignment, I will be able to design and program an FIR DSP filter." The objectives should be expressed in "behavioral" terms, that is, using words that state some measurable outcome.
Identify some initial resources. Start with books at the local bookstore or go to www.Amazon.com or Barnes & Noble at www.barnesandnoble.com. Most cities don't have good technical bookstores, and it's tough to find anything at regular bookstores. Consider yourself lucky if you have a good technical bookstore or a good college bookstore. Plan to get multiple books to give you greater breadth of coverage with multiple explanations, examples, and perspectives. Don't forget to look through your stack of magazine back issues.
Check out online sources. Do one or more Web searches, or go to relevant company Web sites. You may run across an appropriate tutorial, white paper, or application note that will give you what you need. The large semiconductor and equipment manufacturers have tons of stuff on their Web sites, so start digging. Also check out the professional societies and other sources listed in the tables and sidebars.
Watch out for any conferences or seminars on this topic. Usually, such events never occur when you need them, but you might get lucky. If you find one, attend because it will provide a big head start for your own learning.
Organize your materials. Lay them out, mark them up, and then make an outline based on your objectives. See what you have and what you lack, and make an initial list of things to do.
Dig in. Set aside an hour a day or whatever you can to go through the materials. Turn off the radio, CD player, and television. Make a habit of finding some quiet time to read and learn.
Look for a human tutor. You could be working just down the hall from an expert on the very subject you're trying to learn. Pick his or her brain. Ask this person if he/she will help you understand and learn. Take this person to lunch or offer to pay for lessons. Most people will gladly share what they know, if you aren't too proud to ask. The best way to do this is to learn as much as you can on your own. Then, go for the professional, personal help with tough questions or when you get stuck.
Include some hands-on. Is there any hardware you can buy or put together to help you learn it? Maybe there's some software that will help. Buy it or have your employer buy it.
Write a paper or article or teach what you have learned. You have to know it to write it or teach it. There's no better way to learn for yourself than to have to explain it to others.
I generally find it useful to build a "cheat sheet" or other form of summary as I go.
On one hand, it forces me to reinterpret information and figure out what's really important.
On the other hand, I'm building a useful study tool for last-minute revisions, or future refreshing of knowledge.
2.5 hours without breaks seems like a lot. Experiment with different time slots to see what works best (personally, a sequence of 3x(20 work - 5 break) works well)
Pomodoro Technique for time management
http://pomodorotechnique.com/get-started/
(watch "how" tab)
And the code(for programmers)
while(day) {
for (int i = 0; i < 4; i++) {
work(25);
relax(i < 3 ? 5 : 15);
}
}
You should implement methods
void work(int minutes);
void relax(int minutes);
Variable day changes from other threads
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 3 years ago.
Improve this question
Some developers when given a task go straight into the IDE and start coding with very little design. They may have an idea of where the application is going as they are coding. I am 1 of these developers. I do this because I feel that if I spend a lot of time designing my application delivery time will be much higher as compared to if I just sit and code away the ideas in my head. My question is that how does application design effect the delivery time of the project and does it have a big advantage over coding the agile way?
Give you a example, when you want travel,
If your destination is near or in your town, you can start right away.
When you want travel to another country, you need package your self first.
Design is for preparation, without it , you cannot go too far(or go the wrong way).
It is not a black and white situation: for some projects it is much better to jump in and start coding, for some it's better to have an extensive planning stage, and for others it is not clear cut.
If the project is small and simple enough that only a single developer is working on it, and how to build it is obvious enough that they can imagine every aspect of it in their head, then they can very well jump in and start designing.
The need for more extensive planning comes about when you have multiple developers, or when the project is large and complicated enough that a developer cannot know everything possible about how it will work from the outset, because it is too complicated to know all aspects of it in your head.
What you describe only works well if you are writing something well well understood and contained. If it is similar to other software you've written you don't need a new design because you can just re-use the old one. however, if it is something totally new, designing on the fly will get expensive. You'll find yourself rewriting too much of the code or worse, stuck with a poor architecture which slows you down. Likewise, if you need your code to be extensible, planning ahead is necessary. If you need it to work with components from other people, planning ahead is necessary.
This approach only really works well if you are working on your own. If you have to work within a team of people, it is important to have a good plan so that everyone else knows what you think is the end goal. This doesn't reduce creativity it just allows you to make sure everyone is on the same page, and it reduces the opportunities for confusion.
(source: yang.id.au)
Just to add a line of thought to your equation scenario, let me contribute this little bit hereafter: I work in a business called YES INTERNATIONAL CORPORATION (www.yesintl.com.au) Sometimes, it does happen that developers may have developed something before so in that case the design is already in the mind. For example, I have developed database solutions in the past which makes us a very fast delivering corporation compared to our competition when I sit down and start developing a project. More experience will make you super perfect as the time goes by... I hope this helps... Andy
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 3 years ago.
Improve this question
I find way too many projects to get involved in, way to many languages to play with (and way too many cool features within those languages), and way too many books to read...
How do you guys stay focused and actually get anything done, rather than leaving a trail of partially complete "experiments?"
Seems like there are two types of developers: Tinkerers and Entrepreneurs.
Tinkerers want to know how every little thing works. Once they get the hang of something, they're distracted by everything they don't know. The tech world is brutal for a Tinkerer because there's so much to learn and each new year creates more. Tinkerers are proud of their knowledge.
Entrepreneurs want to know enough to build something really great. They think in terms of features and end-user experiences. You never hear them argue about Python over .NET over Java over C because they just don't care. They're more interested in the result of a language versus the language itself. Entrepreneurs are proud of their user-base.
Sounds like you're struggling with your Tinkerer tendencies. I've got the same problem and have found only one thing that helps - find an Entrepreneur developer that you thoroughly respect. When you put the two together, it's unbeatable. The Tinkerer plumbs the depth of every technical nuance. They keep the Entrepreneur technically honest. In turn, the Entrepreneur creates focus and opportunity for the Tinkerer. When they catch you browsing the Scala site (assuming you're not a Scala developer), they reveal a new challenge in your existing project. Not only that, they're much better at understanding what non-Tinkerers want.
Money, and the feeling of accomplishment that goes along with actually finishing something. When I first thought about working for myself I started coming up with ideas of software that I would develop and then later sell. Of course, I really didn't know if what I was making would actually sell, so it was easy to get distracted and jump at new ideas.
So I decided to go with being a contractor/consultant. When you know that there is a buyer for what you're making, and that somebody is waiting on it, it gives you motivation. If it's an interesting or challenging project, there's a rush associated with finishing it. So that adds extra motivation because you want that rush more and more.
Once I got a fairly steady flow of work-for-hire projects, I found that I can stay focused on my side projects better because I have incentive to practice good time management. I give myself a certain amount of time every day or week to work on my side projects, and it helps me stay focused when I take that time.
Of course, I still go off on tangents occasionally and start new side projects as well, but the ones that I am most interested in I have been able to stick with.
Also, after you finish some projects, then you get a better feel for what it actually takes to go from conception to completion, and it makes it a lot easier to do it again and again.
I think a good programmer may well have lots of unfinished "experiments" hanging around, this is a good thing.
Usually with a good manager, you will be held accountable if your work is simply not getting done. If you're a student, though, it's tougher. I realized that it is impossible to learn everything you want to.
I limit myself to only learning 1 or 2 new languages per year, and only 1 book per month. That seems to be a nice balance between programming chaos and getting my job done well.
Kudos for having a great learning attitude :)
Probably the best motivator (for a team or an individual) is to set goals early and often.
One of the best methods I've observed in project management was the introduction of "feature themed weeks" - where the team (or an individual) was set goals or deliverables which aligned under a general flavour, e.g "Customer Features", "Reporting and Metrics" etc. This kept the team/person focused on one area of delivery/effort. It also made it easy to communicate to the customer where progress was being made.
Also.. Try to make your (or your team's) progress visible. If you can establish an automated build process (or some other mechanism) and "publish" incremental implementation of work over a short period of time you can often gain traction and early by-in which can drive results faster (and help aid in early course correction).
1) I leave a utterly MASIVE trail of unfinished stuff, all side projects of course.
2) When I need motivation to work I open my wallet... That usually does it for me.
I'm building an app I plan on selling and see it as a way of making extra money or reducing the amount of time I spend working for other people.
My wife likes this idea and her encouragement has managed to keep me focused longer than normal as it's now "work" rather than "play"
I find that getting involved with the "business" side of the equation helps tremendously. When you see how much benefit the actual users of your program can get out of your creative solutions to their problems - it's an extreme motivation to provide those solutions to them. :-)