I know this is not a technical question, but this is something I believe could be best answered by the technology community. I've been in software development for ~2 years now, but most of the time, it has been a learn as is needed experience. I was recently asked by a friend on how to go about getting a strong foothold on technology so as to be able to easily adapt to new technology that comes up every day.
I'm not sure how to answer his question as my way of approaching this situation has been learn as you need. How would you suggest someone proceed if they were getting into Microsoft technologies today? Where would they start, and how would they proceed? To be able to expand their knowledge to the new advances we see everyday (linq, silverlight, entity framework, mvc framework and the ever expanding list).
Basically I think my question is a mix of both "how to be a better programmer" and how to get to the "next level" in technology (where you are no longer an intermediate programmer, but able to see the whole picture and easily assimilate new technology)
Thanks in advance.
One thing I enjoy is to listen to technology podcasts while I commute, exercise or do household work. You will net become an expert alone by listening to podcasts, but you will get a lot of input. In particular I enjoy .NET Rocks! but Stack Overflow also has a podcast to name a few.
Read, do and try new things. Do that for a few years you'll eventually end up an experienced programmer.
I think this post by the Misfit Geek could help you out a bit. I think it gives some great tips and gives some good advice on how a respected technologist has stayed up on technology.
How did you learn what you know
Hope these help. I also agree that podcast are a great source of info, at least to point you to the best new technologies. I listen to .Net Rocks, Hanselminutes, HerdingCode, and DeepFriedBytes just to name a few. I also follow some good .net releated blogs such as CodeBetter, Devlicio.us, and Los Techies.
Good luck!
I spend at least 1 hour a day just reading blogs, and listening to podcasts. You cant possibly get involved in everything new that comes along, but having knowledge of what's new is just as important as trying new things out.
If you want to specialise in one thing, then that's fine, but always try to include new technologies into your projects, and look for better solutions to things you have done in the past.
You need to follow what the technical community is interested in. Blogs are the best way that I've found to do this. Pick at least 50 that cover a wide range of topics, and you'll know what is coming down the pipe.
Keep involved in podcasts and blogs. Set aside at least 15 minutes a day to ready them or listen to them. Take their ideas, find which ones apply to you or are interested and add it to your personal development plan to learn them.
Here are a few previous posts regarding these:
Podcasts
OR
c# blogs
Interesting project + new technology = motivated learning.
There is no alternative to getting your hands dirty. Take one of the ideas you've had rolling around in your head and implement it using buzzword technologies. Be prepared to realize many hyped technologies are mostly just hype. Hopefully you will find some real gems, change your perceptions of what is possible, and add some tools to your toolbox all while achieving a goal.
Here's the list of Top 200 blogs for software developers. Try to read some of them and subscribe to what you like or find useful.
Blogs are great for spotting trends and finding some advice about the newest technologies, but if you want to learn something in-depth, you need books. Try to read 3 or 4 every year.
Finally, local user groups. Find and meet your fellow developers face-to-face and find out what they're doing and what's on their minds.
Attend meetings of local user groups.
Related
i have been learning laravel and truly its quite fun. but so far the projects i have been doing are just small applications with very few controller files and model. Not much to "Organize" per se. But my question is,
1# how to organize files when a project gets larger and larger?
2#is there any recommended project structure that i could follow from the start of any project so that even if in future the project grows bigger, things are modular and easy to manage with?
thanks.
Welcome to Laravel world :).
The first thing that I have to talk to you before other people: StackOverflow isn't a place for asking opinions. It's should be treated as a technical forum, and questions that you want to ask should be something that won't be leading to a discussion or different opinions from different users (check here "We prefer questions which can be answered, not just discussed", discuss). Simple rule of thumb (I might be wrong but it's my opinion about what StackOverflow is): You ask a question and you should only expect one good answer (That's why we have a "Check if question is solved" feature).
Moving forward from there, I'll answer your question:
There won't be a good answer to your question. Just like what Jeffrey Way said in one of his Laracon speech: "We don't know shit either".
We have a lot of conventions here and there, a lot of rule, but nothing is "right". Every convention has flaws, it's just that some of them are a lot better than rest of the others. So, keep learning.
There are some absolute "Must-have" skills, though, like learning Object Oriented Programming, using Composer. Learn that because it's absolute needs for a PHP programmer.
Making a scalable project is about an experience. The best answer is that you have to face one, either by finding an internship, a junior web development career, being a volunteer to a Laravel project, etc. But another answer is to learn, search "expert answer" about how to build one on Google (like https://www.sitepoint.com/horizontal-scaling-php-apps/), ask Quora. You will find lots of answers because again "We don't know shit either".
Lots of companies have a different system that others don't use. They'll use what they feel fits theirs needs. For your indie project, you'll just have to keep learning and breaking things until you'll find the one. For other companies, you'll find them knowing what they want to do and you have to do everything their way about how to make a scalable project.
Experience, learn and learn, that's the answer.
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 realize that this is a subjective question, so I've marked it as a community wiki. I think that it is pretty specific to programming teams, though, so I've posted it here as opposed to somewhere else.
I'm leading a small game development team (four people) as a side project. We are a disjoint team, with everyone in different places, but we do have some of the mainstays of an organized team.
Source Control
Continuous Integration
Bug Tracking
Document Workspace
Regular Meetings
Calendar / Schedule
How do you keep your small, disjoint teams on-track? I tend to agree with Joel's opinion about when and how to micromanage and know that my team is motivated, but it can be easy to fall off-course when everyone isn't connected in a physical way and doesn't see what other people on the team are doing. Suggestions, feedback, or criticisms are welcome!
Edit: I'm managing the team; I'm not looking for automated tools or anything to do my job for me, just ideas for approach or process that might help everyone feel more "connected" and involved.
You need a Team Leader with specific skills.
Motivator: You have to keep your team Motivated. This is really hard to do, and requires a special personality. Without this skill, small teams like yours are hopeless.
1a. Request thoughtful answers to a controversial question and then after 7 minutes accept one of few answers and go on to something else. This shows that you take the long view and is highly motivating to your contributors
Intelligence: For small projects like this, it's best if the Team Leader knows something about everything. If he knows something about everything, everyone is going to follow him.
Objective: Remaining objective is very key.
Organized: You have to be the most organized out of everyone, because when things get chaotic, people run. And I would say in small projects, this is the skill that most Team Leaders lack.
I have been part of several small projects. I would guess that 90% of them fail. I would say it's primarily due to the Team Leader lacking in certain skills.
BTW. Good Luck. I couldn't be a Team leader. :)
Be a Leader: How to Change People Without Giving Offense or Arousing Resentment from "How To Win Friends and Influence People":
Begin with praise and honest appreciation.
Call attention to other people's mistakes indirectly.
Talk about your own mistakes first.
Ask questions instead of directly giving orders.
Let the other person save face.
Praise every improvement.
Give them a fine reputation to live up to.
Encourage them by making their faults seem easy to correct.
Make the other person happy about doing what you suggest.
Those are my suggestions for some helpful tactics, even if they are rather old as the book was written in 1936.
This is an interesting article about that very topic: Gaming the System.
A manager. Someone has to keep track of where folks are at and how their progress fits in the scope and time-line of the entire project. There isn't really a good way to automate this. It must be done by a human.
Edit When I worked for a game industry company, we always had to meet certain milestones to get payments from the publisher. As the manager you can break down each persons tasks into milestones as well. This way you can track the progress of each developer without bothering those who are on track with their features. It also makes it easier for the developer to know what their deadlines are in nice bite size pieces. If they are consultants, you can even pay them upon meeting their milestones. Money is great motivator ;) Another great motivator is to make all milestones open to the whole team. So if one person falls behind, others can jump in and help her meet it.
I've worked in large and small game development teams for many years and I think the most important thing you can keep in mind to hit milestones and stay on track is discipline.
Game Development seems to suffer immensely from the desire to add more and more features or focus too much energy in something that's just not that much of the final experience. Your best tool for keeping the team on track is the word "No"
So far I've been on the development end of this equation, and by personal preference rejected attempts to place me in a managerial position. Techniques I have observed are:
Set very, perhaps impossibly short deadlines. Developers will be so rushed to achieve the goals that they won't have time for any distractions. They won't have time for refactoring, cleaning up code, indenting, code review or anything else either, but as long as their code compiles they can reach the milestone and worry about debugging it later.
Have a technical project lead so dedicated to the project he'll crack the whip on all others until they produce maximum (visible) output. Also, he'll work lots of overtime and encourage others to do the same.
Weekly meetings, all hands. Some of the information exchanged about what other folks are doing and what they've learned can actually be useful.
Provide standardized equipment, software and development environments. They may be awkward to work with and developers will hate it, but at least they won't end up playing with their configuration when they could be coding.
Have a business-savvy administrative project lead who can keep customers off the developers' backs and filter requirements for them. Anytime a customer "helps" it delays progress by many hours.
Daily standup meetings done properly help a whole lot. If you keep it to:
1 what did you do yesterday?
2 what are you doing today?
3 what problems are you having?
it should remain quick and helpful. Keep in mind #3 is just to state it not to solve it. That is done after the meeting and is facilitated by the development manager or project manager.
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 was recently working with a team to develop an online system. We had worked for several months and were making good progress when the project got canned. We all felt strongly that the projects completion was important and that it would have great outcomes on our consumers productivity. After being frustrated for a while I thought I should ask some people with more experience.
What is the best way to deal with the frustration of a canned project and move forward so that it doesn't hold future possibilities back?
On a well designed project, some of the code you developed can be reused in future projects, making it worthwhile. Even if you can't use any of it however, you and your team probably gained valuable experience that will help in the future as well. Think of it as an expensive team exercise.
Don't put your heart and soul into someone else's project?
I do a lot of work for different people and while some projects are more interesting than others they're not my projects so I wouldn't be too broken up if they got canned. I've got my own stuff I'm working on. No one can terminate those projects but me.
Grieve. Such a loss will produce a grief reaction. Not one as strong as though you had lost a loved one, but it's a grief reaction nonetheless, complete with all those stages of grief.
Failure is the best (and sometimes only) way to learn new things, even if the failure is not your fault. There are many different angles by which you can salvage useful information from this:
Code that is reusable
New technologies or skills garnered from the project
Lessons about project management based on how the failure was handled (maybe the project should have been canceled much sooner, before the team bought into it)
Non-technical ideas that you can reuse in other projects for the company or even in your own endeavors.
I highly recommend doing a postmortem, but don't dwell. Most projects get canned at some point in their cycle and if you let it affect your morale, it becomes a downward spiral from which it's hard to recover. You may become oversensitive to even slight requirements changes.
Attack every project as though it were your own. By this I don't mean invest all of your emotions (as stated here already by Spencer Ruport). But write all your code and organize all your code in a manner that you can easily pull out tools that you might need in the future. You never know if you will need it...but odds are you will. If you write an account manager app...do it in a modular reuseable fashion. If you write an image uploader...write it in a way that it can be ported to any other project you have. Write helper functions around all of your major features to make it more user friendly down the road.
This of course requires some planning prior to losing the gig! No worries. It rarely is because of you that you (the whole team) loses the gig. Some financial decision or business decision is usually at play. In this case most likely the economy is what killed you. In the case that you don't have any physical benefits to the failed project...look at it as a learning experience. Inevitably...no matter how good you are...you probably had something that you did that you don't or no longer agree with. Learn from that. You most likely also did something very cool that you loved. BLOG ABOUT IT! This serves two purposes..you just created something tangible from the project...and you put it somewhere that you won't forget about it.
Sucks all the way around. But at least there is a great market out there right now! Contact me directly if you want my headhunter list (80 technical recruiters in CA and the US).
Two things:
Your Investment in the Project & Code: The fact your team had such strong feelings for the project & were so frustrated on it being canned is a good sign - it means you are a true developer/programmer and are not just doing a half-job for full-pay. So to deal with the project being canned: know you & your team are committed to your work & while that project may not have panned out, you guys sound like a real credit to that project & any other you may work on. It sounds like you just need to find a project/opportunity that has the legs.
My Experience: Projects get canned for all sorts of reasons - budget, lack of confidence from stakeholders, too late to market, changed scope etc. I would enquiry/investigate why your project was canned. If it is budget or lack of stakeholder confidence then it is really good news. It means an opportunity has just presented itself to you & your team. Consider pursuing it!
Either way your team will have grown from the experience: both technically & from a business perspective.
cash the paycheck - that always helps ;-)
ask if you can have the rights to the canned project, since they don't want it, then open-source or commercialize it yourself if you think it's worthy
it's good to care about your work; it's not so good to obsess over it.
there will be other projects even better than that one in the future; they might also get canned, for any number of reasons both rational and irrational
Good example: I once worked with a lady who spent 2 years on a document-imaging project that was canned a few days before it was supposed to go live; it was canned because the new manager did not like the old manager, and the project was his "pet". This lady's reaction: "I'm looking forward to learning something new!"
This can be used to bring your team closer together, if you have the right sort of people. There is nothing quite like working hard on something you believe in and then having it canned. It can depress, but it can also motivate people to want to prove next time that they can do the job, that they had the right idea.
It helps to galvanize the team; we were there, we worked hard, and it was taken from us.
Of course, it's better not to be in that situation to start with, but when you find yourself there use it to build the team.
Sunk cost cannot be used as a reason for the continuance of a project. If the leaders have made a business decision then I'm sure that it is well motivated, however upsetting.
I'd console yourself in that big swings should be celebrated in business, big companies do not win every bid and complete every project they start. So console yourself in having lost once, maybe you might be able to change the way things were done, or focus more on the project stakeholders as well to make sure they understand why your project is worth completing compared to the other projects and business initiatives at the company.
I'll finish with my favourite saying:
"Good judgement comes from experience. Experience comes from bad judgement."
Learn from it!
Watch a Rocky movie (the last one was good) and have a few beers. There's no way not to put yourself into a project, there's no way to not feel bad about a project being terminated or failing, there's no way not to feel negative about the company. What makes a good programmer better is taking all the emotions, anger, etc. and being able to release it and move on with the same focus and dedication that was there with the first project. All part of life and all part of working in IT.
I want to add a "Community" section (Bulletin Board) to my website so everyone can communicate, but I don't know what I'm doing.
How would I go about adding this and which one offers the most documentation and support?
Whatever you do, make certain that you read the instructions on configuring your discussion software to protect you and your community for the worst parts of the internet: spam, spoofing, and abuse.
Make certain that you immediately change the admin password from the one that comes with the installation.
If you leave your communities wide open to all kinds of posting, harvesting, and general mis-use, you'll spend your days playing whack-a-mole with thousands of idiots. Develop your acceptable use policy, configure your boards to support it, then enforce it.
And if the software you are looking at doesn't support things like e-mail verification, moderation, abuse reporting, anti-spamming controls, etc., just keep looking.
Be prepared to spend time managing your community so that it doesn't become another one of the millions of web forums out there full of off topic posts that drive people away from your website.
I think what you needed is a forum software, there are tones of free and open source ones available on the net. DotNetNuke is a .NET one but can be expensive to host and phpBB is another popular choice and there are a lot of cheap hosting solutions.
is your site based on php/mysql or asp/sql? Chances are if you do not know where to even find tables, that you are not able to what you actually want.
HOWEVER, if it's php/mysql, i recommend Cool Php Scripts book. It covers creating sort of a community forum/message board.
As i said again, you are probably not going to do it alone, at least, without a long frustrating learning curve.
You can always post a job and someone would be more than willing to bid on it at elance or rentacoder or any other site of your choice
Wikipedia has a big honking list of forum software. Pick the one that best matches the programming language(s) you're familiar with, the features you need, etc.
This is what you need.
Edit: They don't offer a hosted version there. You can use this instead. It's hosted on it's own site, free, and doesn't require a download.
I find Vanilla to be a much better forum application that phpBB for reasons of aesthetics as well as extensibility. I have not seen/used it in a situation where many sub-forums were required, so depending on your scope it may not be the right choice, but for small-to-medium sized forums I'd suggest trying it first.
First, you need to choose a forum software that matchs your requirements.
Then, just follow the Installation Guide provided by the software you have choosen.
More information at Forum Software Reviews
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I've been making small scale projects for a while now. I haven't started a large project, yet, because I haven't come across anything which I needed and wasn't already accomplished by some other FOSS. Until now. I want to make a program which will allow users to interactively learn secondary languages (I'm kind of want to make it as close to Rosetta Stone as I can).
Right now I'm the only developer since I'm not sure if I'm biting of more than I can chew and don't want to waste any contributors time.
So far I've been planning how the project is going to work and setting up tools to make the project start smoothly and for it to be readily accessible for when other users are ready to contribute to it. I've set up a SourceForge account, a git repository, as well as a document which lists all the features and what the program is going to accomplish.
A basic break down is that the suite is going to be written in java, and the suite will have the ability to support many languages via their locale. The courses for learning the languages will be written in jython. Course-makers will have the ability to use pre-made jython courses to teach their course, or make their own original ones. I'm hoping this will allow for the software to teach copious languages via many mother tongues.
I'm also planning on having a repository of "released courses" which are ones which I (or people who better comprehend the language) think are top-notch courses. This will hopefully make the program seem more professional and secure to the users while allowing third party participation.
With this in mind:
Are there any fatal flaws or suggestions about my project you would like to make?
Is there anything I'm missing about making a big project in general?
Thank you for your time and effort,
Joseph Pond
You will always be biting off more than you can chew if you don't believe other people should consider your project worth their time. This is much more of a leadership point than a programming point. But seriously, work it out: is this idea something that you believe can happen even knowing that you are currently unprepared for many of the challenges that you are about to face? You've given us a rough outline. You'll be giving others a more thorough explanation, and it will soon become obvious that you've overlooked some stuff. Nobody can keep that from happening to you. Having said that, if you think that you have a good grasp of the requirements of most of the components and you believe you can thoroughly describe the requirements to others with appropriate skills, I'd say go for it.
P.S. -- If you have any mock-ups, that would make it seem like a sweet deal from a prospective developer's perspective. It sounds like the selling point is the extensibility of easily designing new courses. If that's so, give an idea of the basic structure of the Jython. When my supervisor gives me a task that I understand thoroughly, I'd rather he didn't show me how to get started or what design or implementation to use. When I have no idea what he's talking about, the roughest of sketches gives me days of a head start.
Are you also the only analyst, translator, technical writer, and tester? This sounds like a large undertaking for one person. Do you have a deadline? In my opinion you will need at least another developer and tester. Even more if you have tight deadlines.
Just find the right person who really agrees with your idea and will take the ownership.
I had been involved in several projects but I dropped out some and only worked on the one I really interested in. So, look at it in the reverse side, looking for a contributor is not easy and must find the person has the things I mentioned about. Then, you can talk about keep contact,, system... project manage..etc. If you can't find the right person, even you have a good system, you are just wasting your time and going nowhere.
Okay, a couple things. First, it's better never to do a big project. Do lots of small projects instead. If it works out that what you get at the end is a big thing, that's good.
Second, a lot of times what works best for this of thing is to think about how you can make something to make it all easier. in this case, you have two issues: making something that does the various operations needed to display and give feedback (I'm working through a Rosetta Stone course myself, they're pretty cool.)
You're really thinking about a course authoring system; you can't write all the materials for all the languages, so you have to make it easy to do the authoring.
This sounds like a job for a DSL, a domain specific language.
And it sounds like a really cool idea.