As a dev who spent a couple of weeks trying to configure an automated Amazon EC2 setup, I can totally relate to what they're saying. Not really something new, but a good reminder to keep it simple, and I appreciate them saying what providers they used.
I've interviewed a guy from IBM before. He insisted on commenting everything and having getters and setters for all of his fields.
If you google you can find out why I didn't think this was such a good idea...
https://www.google.co.uk/search?sugexp=chrome,mod=11&sou...
Being in a company has a lot to do with how well you get along with people. You're new, and so I suggest that you listen carefully, ask questions about things that you don't understand (otherwise you'll feel like a dumbass next time they bring it up, and you still don't know what they're talking about).
When you've been working somewhere for a while you also tend to dismiss the problems around you. Make sure you note down all of the things that you find wrong about the place - ask people why these things are they way that they are - it could be a misunderstanding on your part, but it could also be that there are genuinely things that need fixing.
Make sure you keep a notepad on you - note down everything that you learn, problems that you see etc - it'll come in handy.
After a couple of weeks you can start acting on fixing the problems that you've seen - if you actively seek to solve problems, then you can become a hero in the company - the guy that made our lives better.
Lastly remember that if you want something you'll have to fight for it. Don't be afraid to disagree with people, but you have to play a fine game when you've just come into the company - you don't want to piss people off, but you also don't want to set the expectation that you're OK with shitty code.
> I've interviewed a guy from IBM before. He insisted on commenting everything and having getters and setters for all of his fields.
A co-worker of mine used to work for IBM. He said he commented everything. However, he wrote them in Spanish. So your code comments should be appropriate for the environment :)
> Being in a company has a lot to do with how well you get along with people. You're new, and so I suggest that you listen carefully, ask questions about things that you don't understand (otherwise you'll feel like a dumbass next time they bring it up, and you still don't know what they're talking about).
Definitely do this. If someone mentions an acronym or project, either interject or remind yourself to ask later what it is. Which one is appropriate obviously depends on the context of the situation.
> When you've been working somewhere for a while you also tend to dismiss the problems around you. Make sure you note down all of the things that you find wrong about the place - ask people why these things are they way that they are - it could be a misunderstanding on your part, but it could also be that there are genuinely things that need fixing.
There are a lot of things done because "that's the way they are" and no one questions that. You should probably question why. Sometimes things are done that way because it was the best solution at the time. However, technology and use cases change.
> Make sure you keep a notepad on you - note down everything that you learn, problems that you see etc - it'll come in handy.
You can also make notes about people. Where they are in the org chart, what they're responsible for, who referred you to them, and maybe even some of their info, like they're a fan of a particular football team or something. That info can help you make small talk and fit in with the group faster. You'll meet too many people too quickly to internalize it all at one time, so the notes will help as a temporary crutch (don't be a stalker, and don't write anything you wouldn't want anyone to read). Along those lines, sometimes you just have to initiate joining a group. You can't always wait for them to invite you in.
> After a couple of weeks you can start acting on fixing the problems that you've seen - if you actively seek to solve problems, then you can become a hero in the company - the guy that made our lives better.
This is true. I've seen it happen.
> Lastly remember that if you want something you'll have to fight for it. Don't be afraid to disagree with people, but you have to play a fine game when you've just come into the company - you don't want to piss people off, but you also don't want to set the expectation that you're OK with shitty code.
We have a philosophy where I work called "disagree and commit." There are too many opinions from too many people to ever work out everything ahead of time. Sometimes you have to just say "I disagree with this idea, but I accept we've decided to go this way, and I'll give it 110%." The trick is knowing when to hash it out some more and when to just shut up and get something done. There are many more problems to be solved, and you can't win every battle.
Well to answer the last question - yes a decent dev will be able to MAKE the frontend and backend. Designing the front end is a different story...
The advice I give in these situations is to sell the product before you have anything. See if your boss would buy it - tell him you've found a great solution which does x, and y, and costs $Z per month. Don't underprice your offering - if it's good, and it solves a real problem, then people will be willing to pay a decent amount for it. I don't know what prices you were thinking of, but you could tell him it costs $50 a month.
If that's too high for him, ask if you could get it down to $30 if he'd be willing to pay for it.
Before you pay a developer, do a front end design - make it look nice (I'd steal someone elses design), and have it explain what your service does. Then set up adwords or advertise your site, and see if anyone clicks to buy the thing.
If people are clicking to try what you've got then you might have a product -otherwise you've just saved yourself a shit load of money by not building the whole friggin thing.
I'd be quite interested in meeting up once a week with people at the beginning stages of creating a startup. It could be a good way to say what you did this week, where you're aiming to be next week, problems etc that have happened along the way.
Could be a good way to motivate people to do what they say, and get help from others. It'd be good to note down what people want to achieve each week, submit it all somewhere centrally, and then go around each person who gets 2 minutes to say what they did, problems they had, where they will be next week...
