Related
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 6 years ago.
Improve this question
Does anyone know ways to use GML programming skills to find or make work, such as freelance work using Game Maker?
I was thinking of doing freelance game prototyping work for people looking for a quick mock-up and getting the feel for their game, that can be done within a week or a few days.
If anyone has an idea, could someone please help me out? Thank you.
Personally, I started out using GameMaker as a hobby, and I've worked on some small projects for other people, but I eventually got hired as a website and database programmer rather than as a game programmer.
Unless you find a team that is already using GameMaker for its project(s), your experience with GML may not count for much on its own, as the language is only useful inside GameMaker itself. However, understanding GML means that you also have basic programming skills, and once you know one way of programming it goes much quicker to learn another.
GameMaker made programming easy and interesting for me, but other languages gave me the tools needed for non-game projects.
A company may not hire you based on the fact that you know GameMaker specifically, but it may hire you because you know programming. It could be wise to research other programming languages and learn the basics of how they work.
If you are to sell your skills to a client, they will likely care more about the end result than the exact road you took to get there. For example, if the job is to make a game that works on Android phones, that is something GameMaker can do, and by extension it is something you could do.
If GameMaker doesn't seem like the tool for the job, use what you learned from GameMaker to help you understand a different program/framework. Even if you focus on GameMaker, you may need other languages if you are to set up an online game server or scoreboard.
A lot of successful games have been made with GameMaker, so it's definitely possible to make a living by using it. The Showcase section on the official homepage shows us games like Hotline Miami and Undertale - big hits in the Steam store.
This article from GameMakerBlog.com lists a few people who's made it big. Most important, I would say, is "True Valhalla", who gives the community running updates on how his business is going. You can find his blog linked in the article. He has written a book about how to make money by selling apps and games, which could be well worth checking out.
If you wish to focus on freelance work using GameMaker alone, then make sure to understand the ins and outs of the program so that you can be as flexible as possible. Make sure that you understand how the movement functions work, how to do collision checking, how to work with data structures, how to work with views and surfaces, and so on.
The technical skill doesn't need to be perfect, but you need to have an idea of what to do and how in order to realize your ideas within a reasonable time frame. Practice until you feel comfortable taking a game from concept to demo in a short time, and build a collection of examples and engines that could be useful to you. If you can reuse a script, that's a lot better than writing it from scratch for every new game you make.
Finally: Marketing yourself. In order to become attractive to potential clients, it helps to demonstrate your expertise by publishing your work online. Make yourself visible. Post screenshots, videos, and playable versions of games you've made. You could blog about game development, or build up a small profile by helping people online and getting credit for it.
Any project you can point to and say "I worked on this" makes you a more credible developer. If you are just starting out you may not have any projects yet, so one suggestion would be to make a small mini-game and publish it in an app store. You may even publish it for free. For your first games, exposure could be as valuable as sales.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
G'day,
I'm always trying to improve my performance as a developer and, after listening to this interesting podcast on the topic, I was wondering if people think it is worthwhile asking for feedback from colleagues.
I am thinking of obtaining feedback anonymously in the manner suggested in the podcast by using the Rypple site. And by asking one single, short question that directly addresses a specific aspect of my work or behaviour. For example, I'm looking at questions such as:
What can I do to improve the way in which the development team and the operational work together?,
How can I help you be more effective in your job interfacing with our major client?,
What parts of my technique could I improve based on the presentation I gave today?
etc.
Edit: I am not talking about general aspects, but specifically about how my performance as a developer can be improved. Communication and working with others is a large part of working with others in a company.
Edit: These additional questions are in response to a comment to my original question by JB King.
Further examples of possible questions that could provide useful feedback to help you improve as a developer are:
Am I becoming too focused or obsessive in my solution toolset?
What technology do you think I should learn to expand the team's capabilities?
What technology do you think I should focus on to improve the team's overall capabilities?
All of these directly address my personal progress as a developer.
cheers,
If you want to get honest feedback about what you are doing, you may want to find someone that observes what you do, and just ask their opinion, perhaps while having a beer. :)
But, it is important that you don't get defensive in any way, as you are asking for honesty.
And, you should consider making changes based on what they say, as that will help others to see that you are not only open to criticism, but willing to adapt, to become a better developer.
But, ultimately, you need to get an idea what type of programmer you want to be. Then it is useful if you have someone that you work with that exemplifies those qualities, then you can develop a relationship to see if they can help you become a better programmer.
For example, I knew an architect who would always pull a chair over and sit down when answering a question, so he was always on the level of the developer. That little action was so impressive to me, as it was a simple action, but it showed a willingness to bring himself to the level of others. That is how I want to be seen as I mentor others.
I think asking for anonymous feedback is bad, in part because it shows that there is a communication problem on the team, where people are not willing to be open with their feelings and opinions. The team lead should deal with that, as it could eventually be damaging to the team, if people keep their true opinions bottled up rather than expressing them, in order to help the team to be better.
I'd actually recommend not being anonymous when asking for criticism. One of your stated goals is to improve communication with colleagues; I think you might improve this better by actually talking with them instead of using a tool.
Being able to take criticism in person will show people you are confident and serious about improving. Face time is unfortunately underrated in our industry.
Yes, asking for feedback from colleagues is worthwhile. Often you don't know what you are doing great and where you could improve without getting at least a second opinion, if not a third, fourth, and so on.
Anonymity gives the benefit that those answering don't have to fear retaliation. Sometimes this works well and the result is honest feedback and sometimes people may enter stupid things trying to be funny. Que sera, sera.
I am not sure much good will come of it. I kinda agree with James on this one.
What might be better is to have some development workshops in your team. You could do it in such a way that each week 1 developer has the floor for an hour. Find a meeting room and a projector (if you have one) and let this developer present his / her discovery to the rest of the team.
At any point in time there are huge changes happening in the industry, so there should be a lot of areas to cover, for example - one week a certain developer could talk on up and coming changes in .net framework v4 (just an example), while another week yet another developer can talk about the benefits of shorter scrum iterations (again just an example).
The idea is the developer shouldn't be forced into presenting, and he/she should decide his or her own topic of interest.
This exercise might help strengthen communication in your team, and in this way the whole team is geared towards improving development skills.
This is the good idea, bad idea which I've seen is to take this idea too far, and expect developers to go away for weekends to so called coding dojos - yeah how fun (not).
Make sure these presentations are happening during normal paid business hours, or you'll have a riot.
"How can we do our jobs more effectively?" is a great question, and well worth asking!
But you should always discuss it openly. It's about as innocent a question as one can ask in the professional world, so if you tell people to discuss it anonymously, they'll think something funny is going on, even if that's not the case. And if you can't discuss such an innocent topic openly, your organization has serious problems.
Also, if you're going to ask questions like that, you need to pay attention to the answers, and either act on them or explain why you won't. People can handle, "Good point, but we're not going to do it that way, here's why." But it's pretty demoralizing to answer a question like that - especially if you made a lot of effort - and then feel like you've been ignored.
A good question that I've found to ask is: "Would you recommend this app to someone else?" and start the conversation there.
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 2 years ago.
Improve this question
I've been in the business of developing hardware and software for 19 years now. In the earlier days the projects and teams I worked on were smaller, much more effective and more fun.
The effect of the input of one single developer to the final product and to its success was evident to everybody. We had direct contact to and feedback from the customers. This was rewarding for our work and a very effective way to improve the product.
With the years the complexity of hard and software increases and more and more people were needed to get things done on time. The downside of the trend to bigger teams for me is that the contribution of a single developer to the project success gets smaller and smaller. And we lose the contact to real world of the users and customers because of growing QA departments more and more.
I always enjoyed my work and kept in touch with latest technologies like OOP, UML, .NET, and whatever. I already worked a few years as a team leader but I didn't like it very much because I missed developing and coding.
I'm just frustrated about the fact that my piece of the whole "thing" we're working on gets smaller and smaller and I lose the overview about it and the contact to the ground. Please don't understand me wrong, I don't want to cry for the good old days but for me the work on more and more specialized sub modules of a giant system simply gets more and more boring.
I'm wondering if I'm alone feeling like that and maybe if you have some advice how to bring the fun back to my work. And sorry, no, I'm not interested in working on an open source project in my free time. Nine hours a day in front of a computer screen are enough, life is more than coding...
I also require interaction with and feedback from the customer. However, a customer can be many things. As long as I'm satisfying someone (end user, team leader, big boss, etc.) then that's enough for me. The interaction itself is the key factor.
As for the feeling of pride and ownership from having a large impact on the system, again it's a matter of focus. You are still creating something, even if it's a smaller piece of the whole.
I long ago realized that I'm a small fish in a big pond. Learning to feel happy about my place in that pond was the only solution.
IOW, it's all relative!
I guess it all depends, there is a degree of camaraderie that comes with smaller teams and a lesser chance of ego's colliding. I have experienced both and they both have their upsides and downsides. To be honest, while working on a larger team I learned so much from other programmers, you think you know a lot, but someone always knows more.
It all depends on the team and the egos of the individuals.
When working on a team with ego problems, it doesn't matter how cool the technology is or how much interaction you get with the customers. One bad apple can drain all of the fun out of working on an otherwise cool project.
On the other hand, if the team has gelled, it matters very little if the technology is out-of-date, or the business problem is boring. Working on an back-office accounting system using VI and 10-year-old beta C++ compilers can still be invigorating when you feel like your peers are in the same fight and have your back. When you learn from others and are listened to when you have some new approach to try. When the developers control the build/test/deploy process so that it's sane and improves the lives (and sleep patterns) of the support team. When your peers (and you them) are always willing to help with an obscure language issue or work through a maddening bug. That what makes programming fun and interesting regardless of everything else.
You may want to consider changing companies back to a smaller company where you had a broader set of responsiblities, for one idea. Also, what are changes in the process that would help with the points you don't like?
I do have the question of what you mean by large here? Would a team of 50 people in a project be large? Or is it more like 1,000 to be large? On one level I'm asking for scale as there are teams beyond large if one wants to look at all the developers that work on Microsoft's big products like Office and Windows while at the other end of the spectrum are the one person development teams that do it all.
I'd second Kelly's answer that it depends on the team and egos for another big factor in things. What do you consider fun? Is it finding more efficient ways to solve problems that have poor solutions? Is it conquering a Millenium puzzle? Or is seeing someone smile while using your software what makes it fun? Lots of different possible answers and while I can make suggestions, how good or bad they are is totally for you to interpret.
I don't think you're alone in disliking how as a company matures the process can change as new people in various roles are added with increased bureaucracy and losing agility as it may take more signatures to get a change to be allowed or developers lose that touch to the customer of their product. There is a spectrum of various ways to produce software and some places may have less process in place and be focusing on "just make it work" while other places may want the process to be much more formal and organized with 1,001 policies for every little thing. At which end do you want to be working?
To answer the question as it's asked in the title: No!
I feel very similar and talked to many others who think the same. From my experience small teams are much more fun to work with and by that (and some other reasons) they're much more effective.
Thank you all for your interesting and valuable answers (and for correcting grammar and spelling :-)
You gave me some big points to think about:
The missing interaction with custumers (whatever "customer" means)
The interaction and feedback inside the developer team
What means fun for me. I think its more the smile in the face of the user than the use of cutting-edge technology.
How to deal with the sometimes overwhelming processes.
Last but not least to find my comfortable place in the big pond. It may be not the one where I'm staying at the moment...
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 7 years ago.
Improve this question
My organization has been experimenting with the introduction of more "Agile" methods. We've been trying the Scrum approach for a short while, and most of the team has, more or less, adapted to it. I like it as a whole, but I'm concerned about one potentially severe impact of the methodology: as teams are consistently focused on features and backlog items, and testers are more integrated with the overall development process, it seems like skill sets are becoming blurred, and people are sensing less respect for their individual abilities.
Some of our developers are excellent at server-side technologies and optimization of heavy-weight data provisioning. Others have invested a large amount of their careers learning GUI technologies and have developed a fundamental understanding of users and usability in an application. Neither skill set is better than the other, but they are certainly different.
Is this an inevitable result of the Scrum process? Since everyone on the team (as I understand it) contributes to satisfying the next feature/requirement, backlog item, or testing goal at hand, the underlying philosophy seems to be "anyone can do it." This is, in my experience, simply not true. Most engineers (developers, testers, etc.) have a particular skill set they have honed over the years, and the Scrum methodology, in my mind, tends to devalue those very abilities they were previously respected for.
Here's an example for clarification:
If a sudden change of technology occurs on the server-side data provisioning, and every item on the to-do list for the sprint is based on this new change, the GUI developers (who likely haven't had time to become acclimated with the new technology) might not be able to contribute to the sprint. At the very least, they will need to invest time to get ramped up, and then their code will be suspect because of their lack of experience.
I understand the need for rapid development to discourage "role silos" but doesn't this discount one fundamental reality: people develop skills in accordance to necessity, their interests, or their experiences. People seem to be less motivated when they perceive their position is one of "plug-ability" (e.g. we can "plug" anyone in to do this particular task). How does Scrum address this? If it doesn't, has anyone addressed this when adopting the Scrum methodology?
The short answer is an emphatic NO! Scrum does not blur or depreciate the skills required for specialization. Scrum does not promote generalization.
The long answer is that in Scrum, the most important thing is to get the work "Done". The team, as a team (as opposed to a collection of individual "stars") collaborate, as needed, in order to get the job done. Whatever it takes - however they want (Scrum is about self managing, self motivating teams, right?).
What this means is that a scrum team may be composed of several specialists, who primarily do what they specialized in (DBA, Graphic Design, even technical writers). The team, as a whole, should have all of the skills required to fulfill the requirements. This is not the same as saying that each team member has to have all of the skills aforementioned.
That being said, it is often desired - often by the members themselves - that members other than the specialists be at least adequate in skills different from their specialty. Another poster already mentioned Scott Ambler's "General Specialist". This helps the team when there's too much work of one kind, when the specialist is absent, and it helps the member when he really would like to gain experience outside his specialty.
Given that the team is self organizing, if for some reason a specialist finds himself in the middle of the sprint, without any work to do in his specialty, the best way to deal with it, is to simply ask the specialist what he wants to do. Let the team decide. The specialist can decide to help in his other areas of adequacy, do a POC for the next sprint, "shore-up" the defenses by fixing some long forgotten technical debt, or shine the shoes of the members who are working.
Yup. I don't know if this is the long answer. But it definitely was a long answer.
:-)
The point of Scrum is for the developers to self-organize. We use scrum where I am, and jobs get passively sorted by a person's focus. We don't do it on purpose with a chart and list, it just happens. We all know who's best at what, or what their main/secondary focuses are. If the 'main' person needs help, they get the person/people with a secondary focus in it to help. We do get plenty of tasks not necessarily in line with whatever our particular focus is, but you always know who to ask for help then.
For your example - I don't know that if you say had 3 server guys and 5 gui guys, that you'd expect to get all the work done in that sprint (if the server guys + some help from the others wasn't enough). The way the sprint is supposed to work is that from a prioritized list, the developers pick what they think they can get done in that 30-day timeframe. If that meant the GUI guys needed 2 days of server-side training in order to help, that's what it'd mean. Unless there were concurrent things also high up the list that they could do instead. The sprint tasks are not supposed to be dictated by management as a psuedo-deadline.
If you have a Safari account, there's an interesting mostly case-study book by one of the guy/s who invented scrum.
I've been working as a ScrumMaster for about 18 months and have worked with two different teams. I initially expected to experience the potential issues you raise but this has not been the case. What I generally observe is that the team evolves into a mixture of specialists and generalists as people find the appropriate role for themselves - one that they can enjoy and be successful at. This is self-organisation at work. I have never had a case where our specialists were sitting idle.
If this did occur, I would expect it to be raised as an issue in Sprint Retrospective and the team would discuss how to improve the situation. The most obvious (and brutal) conclusion would be to change the team composition.
I am not sure why skill set will get blurred. There is a fair amount of confusion in the agile world. Scrum is a project management process and not a software development process and should not be seen as one. The engineers have to follow their own methodologies like TDD or extreme programming to add their own part to being agile.
Nothing goes away in scrum.
PM's still document as they go
Architects still architect their components. The only thing is they just delay some major decisions to more responsible point in time.
Developers should still follow best practices such as SOLID principles to enable for refactoring in a consistent manner as features change.
I think Scott Ambler addresses this issue very thoroughly in http://www.agilemodeling.com/essays/generalizingSpecialists.htm...
His concept of a Generalizing Specialist is exactly the thing Collective Ownership / Scrum Team calls for, and makes total sense to me.
Its hard to achieve in real life though ;-)
If you find for any reason ('sudden change of technology' or not) that the amount of work required for a system over a sprint is greater than the amount available then there's a problem with your scheduling.
One fix is that, as you suggest, you take programmers from other areas and throw them onto the mix. How well this works depends on the skills of that person and how different the problem domain is, but treating programmers as generic units that can be farmed out as needed is generally not a successful strategy for developing software.
This is still a scheduling problem though.
The best thing about Scrum is exactly the fact that skills do get a bit blurred! The point is to avoid silos at all costs by spreading specialist knowledge across the team and letting people work a bit outside their comfort zone.
Obviously this is not for everybody. Some developers are happy in their own narrow specialist field and such people are more of a hindrance in a Scrum process than an asset, whereas well-rounded and multi-talented people who are determined to get the job done, usually adapt very very well to it and are far more productive.
One of the key benefits of Scrum is to get the whole team actually involved and invested into the project instead of tackling their own special tasks and then riding off to the horizon. I'd claim that for most people, this is a far more rewarding way of working than the conveyor belt -approach of waterfall processes.
So I'd advise to boldly embrace the mixing of skills and having people come together to take down nasty problems instead of relying on specialist silos. The result of teams consisting of motivated people can be surprising.
Sounds like this would lead to more well-rounded developers, and also allow those who are experts in certain areas to continue to contribute their expertise.
I haven't used Scrum much myself (yet), but from your description, these types of teams would lead to a team/organization that is also more well-rounded as a whole - and shouldn't that be the goal of any team?
Handling sudden changes is part of Agile and this may mean that some people have to go off and learn new skills. Course this is more within the general Agile philosophy than anything Scrum-specific. There may be some extreme cases where the customer or business decides to change the world by bringing in something new and thus has to handle the subsequent pain of those people ramping up but if this is what they want and the developers are overruled, then there are only a couple of choices: (Take your lumps and try to handle the major changes) or (quit and get out of there).
While there can be some cases where someone that has specialized in something may be able to do things faster, this doesn't necessarily mean much if that is just one person on the team that is an expert and there is enough work in that area for 10 people for the whole sprint. Should those not an expert simply not do that work and let that one person attempt to get through as much as he or she can? I don't think so but there should be something to be said for those that aren't the best at something still trying to get done what they can get done.
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 8 years ago.
Improve this question
Yesterday I had a team leader of another team say that they took a while to figure out something I wrote on a wiki page because I referred to obtaining code from source control as "checking out" which apparently confused them. They said that they were use to Clear Case and had only heard of the term "joining a project" and said that they haven't really programmed much for a long time.
While this is fine, what it then made me think of is the different types of team leaders I've had over the years. I've had some that have been almost purely managerial and I've had those that are programmers that do managerial things at the same time.
Do people have a preference as to what kind of team leader they have? How do you care if your team lead is active in the development of your product? I find team leaders who actually sit and code like the rest of the team more likely to understand things like (from my experience):
things aren't always as simple as they sound. Team leaders I've had who don't code or rarely code at all believe everything is a piece of cake and shouldn't take much time at all (which perhaps might be the case if you want to hack it together)
they are more understanding that developers don't always like sitting in long meetings and do their best to avoid getting their team into as many pointless meetings as possible
they understand what you say from a technical point of view. Those that might not have coded for a while might not be up to speed with a lot of the new technologies, techniques or lingo
I find it much more satisfying to have a team leader who has the mind of a developer and likes to get their hands dirty in the code as well. Perhaps there are some people out there that like team leads who distance themselves from the actual coding side of things and simply doles out the work, or perhaps another type of team leader that I haven't mentioned?
A team leader has to be a coder -- they can't lead the team unless the team respects them and where they're taking everyone.
A team manager, on the other hand, can either be a coder or someone who is just well organised and knows when to ask questions and interface to other management.
It is possible to find both a manager and a leader in the same person, but more often the roles (should be) separate and distinct.
You should read the book Managing Humans. I am of the opinion managers should keep their hands out of the code. They have more important responsibilities like keeping people away from developers, so they can do their job. Having them jump into development creates confusion as they aren't in it enough to know what's going on and have their time divided between that and other things, so it is difficult to count on them for major pieces of functionality. Plus, it really sucks when you have to tell your manager that something they just wrote needs to be changed, and you have to go back and redo it. Managers are really their to jump on the grenades for the rest of the team, so they can focus on accomplishing the task at hand.
That being said, should manager's know about software engineering? Yes of course they should, that's the field they are in. Should be know how to code in the latest and greatest whiz bang technology? That shouldn't really matter as long as they get how software development works.
I have no preference, I can't, I have to work with all of them, even though too many cooks spoil the broth. On a multi-developer typical project I have a technical lead, project manager and a non-technical customer. Of course, divisional and programme management will each stick their head in.
There are a number of types of leader, each have their own traits:
Non-technical customer: "The customer is always right." Often wants a moon-on-a-stick. Will call both the management and the technical bods and take the best answer as gospel.
Team manager/line manager: Somewhat pastoral role. Not particularly interested in the project I'm working on right now. Steps in when there is a decision to be made between project priorities. Probably really wants to be a coder, and delegates all the rest of his work that he can to his subordinates.
Project manager: Varying degrees of technical know-how. Is concerned only with timescales and costs. Does not understand, "I don't know how long its going to take, I need to play with it for a couple of days first to get a feel."
Team leader/technical lead: Just another developer, but with more experience. Responsible for technical decision making that will affect the whole project. Often fighting with the project manager to carry out good engineering practice, even though it will take longer in the short term.
Team leader/glorified secretary: Someone who is supposed to lead the team, but acts as more of a secretary. (Usually a grade above the team). Answers the phones, insulates customers from the technical bods. This works fine until they ask a technical question, where the glorified secretary tries to blag his/her way out of it, and eventually they work around the secretary and talk direct to the team.
We typically have a PM (non technical) who manages the project from an admin. viewpoint and a Tech Lead who manages the technical aspects and provides technical leadership to the team.
The Tech Lead will code parts of the project and will probably be the main (only) developer for the "Proof of Concept" stage.
On some smaller projects, they are the same person but it's a rare combination.
The absolute worst Software Leads/Chief Software Engineers that I've worked with were the ones that wanted to be intimately involved in the technical details. Too many important tasks were either missed or just not done. Managing a team is a full-time job. If the lead wants to get involved in the technical aspects it will certainly come at the expense of the managerial aspects.
I’ve only had 2 Software Leads/Chief Software Engineers out of dozens that I thought were worthwhile. While both were previously software engineers, those days were long gone for both of them. They knew it. They didn’t even try to pretend. Their job was now to manage. Their job was to make sure the developers had every chance to succeed. They did their best to remove all obstacles and make sure everyone was making progress.
I have a theory, but have never seen it in action, that the best software lead would be someone who is not, nor ever has been a software developer. They specialize in the true spirit of management, specifically that of being a facilitator. Unfortunately, most managers are more politically motivated or are just in the job because they've reached their pinnacle technically.