I have recently completed my bachelor's degree in Computer Engineer. I have had one small internship till now.
I have little coding experience.
After searching for months (Does not mean I am desperate for the job-Just wanted to clarify so that your answer is not based on it), I have been offered a job at a start-up to design and develop their web application for user interaction and management. I am the sole technical hire and will be the only person responsible for the development of the platform. The founders, though highly educated, do not have any sort of technical background.
It seems like an interesting opportunity but I am wondering if it too much responsibility too early?
I know this is not a standard programming question but I think this is a programming ability understanding type of question.
I would highly value your insight on this subject.
Thank you.
Just looked at your LinkedIn profile. Looks like you have great entry-level programmer qualifications.
Being the sole technical member of the team, with limited industry experience may be a great opportunity for growth.
However, the flip side argument is that you may be losing out on opportunities to grow with adequate mentorship. In all reality, the college/university CS/CE curriculum does not typically prepare you to handle real-world problems that senior-level software engineers address daily. In a company where you are NOT the sole technical staff member, you will have the opportunity to collaborate with and learn from experienced pros. In my opinion, that is a huge factor in selecting your first job.
So ... assuming this startup grows quickly ... are you qualified to:
Make day-to-day technical decisions regarding scaling, security, and prioritization of product features?
Interview, hire and evaluate the performance of additional technical personnel?
Develop the full-stack of a web application including setting up and administering server, database, APIs and associated frameworks, client side technologies?
If you are uncomfortable with any of the above (which is a very limited set of questions) you probably aren't yet ready. It takes a long time before any of us are. Before I took my first leadership position in a startup, I had over 10 years of experience in multiple industries and with several technologies. But that's me ... you have to make this decision for yourself.
Depends on the type of the company. If there's going to be interaction between the users and the site a lot and it just doesn't serve the purpose of providing information, then you'll have to handle things on the server side as well to provide proper response and you need to be quite good with your stack and as a fresher, it isn't quite recommended to be a sole performer in the technical section of an entire firm.
Since you tell, web application, I assume the user does have to interact. I wouldn't go for it if I were you. But you haven't told about the level of expertise you possess in your skill set. So, can't say whether or not you'll be able to handle it.
and this is just my opinion btw.
Related
I'm about to start work on a project that will contain an iOS client, a server backend and eventually a web client. The service will start small, but might potentially become fairly large in terms of number of users and data transmitted.
I have very little background in server programming (other than having a longer Linux phase back in the 90s), and mostly just do frontend dev work, with my primary platform and language of choice being iOS and objc/swift. Now I'm in the position where I most likely will be hiring a full-time dev to work on the backend and web frontend, starting in January, but I honestly have no idea what software platform I should be basing the server-side stuff on, and therefor no idea what I should look for in a new hire.
What do people recommend for a server-side software platform for something that needs to be very scalable? I'm thinking we might to Amazon EC2 for the hosting, and I think it might be easier to find .NET devs here, so I'm kinda leaning towards that, but I don't want to base such a crucial decision on just what I have at hand here now.
<wry>
Follow the fads! Pick the flavor of the day for every piece, that way when the fad fades it will be unsupportable and undocumented.
</wry>
<expensive style="slow:10; methodical:7; costOverrun:50%">
Oh, wait, no... Perhaps find an expensive consultant with comfort in all the stable and long-term supportable candidates and map out the data structure and needs for performance for your app.
</expensive>
<structural>If you have table based data pick something SQLy and if you have tree based data go for something less SQLy (maybe not all the way to M but who knows...).
If you are competing with another product choose whether you are going for quick turn around feature adds, performance, stability, or some other competitive point.
Decide where you want to draw the line on how much you want to have done on the server vs client. If you invest in the server, you can get great performance and reduce platform variability. However you will need to build security in from the ground and stay on top of it. If you process on the client your performance will appear linked to the customers's investment in HW.</structural>
<nextSteps>
Your bounty is running out, and you haven't given us much info to help you pick a platform. I suggest identifying as much information as you have and decide if you can disclose enough to get help in this public forum or hire someone you can get to sign a non-disclosure agreement so that you can really dig into the architectural requirements.
Please note that http://norvig.com/21-days.html Peter Norvig (read to see why he is authoritative) quotes Alan Perlis: "A language that doesn't affect the way you think about programming, is not worth knowing". The architecture question should be answered by someone who knows enough languages and platforms to understand the way that programmers who use it think. You REALLY don't want someone who know Java and can read someone else's php to write your php. You want someone who can think in the language you choose. You want an old experienced programmer who is multilingual to review your product to help you identify the language and platform that best meets your business needs.
</nextSteps>
Some of this is tongue-in-cheek, but perhaps the best advice I can offer you is to hire the best person in your market and trust them.
The nature of our business often has 2-3 remote developers working on a single project (mostly Rails), and each one currently has carte blanche access to source so they can checkout, run, and develop locally.
The problem is any one of them could ship the whole base out the back door. Overseas legal action seems futile.
I'm guessing the best way would be separation of duty type of strategy where a contractor only gets specific portions of code - but how can they run and test the full project?
I'm looking for advice, strategies, or even software solutions to mitigate this risk.
Thanks a ton.
You should really allow only trusted people to handle your family jewels. I can't think of any stronger sign of trust a software company can show than to give someone complete access to their source.
That being said, a few ideas come to mind.
If they're consultants, you should see if you can get some kind of business agreement with an entity in the remote country that can take care of local legal hassles for you. US companies with offices in India do this all the time.
Perhaps you can give access to non-important pieces of the software to the untrusted parties and have them work only on that? The unit testing can be done by them on the pieces but the integ. tests that require the entire system have to be done by you.
It might also be possible for them to use the 'important' parts of the code as a service from a server you provide rather than as modules locally. Admittedly, this requires some reengineering but it might be worth it.
The bottom line is what Stephen said. Low priced off-shore contractors come with certain liabilities. If you're not willing to accept that, you'll have to change your mode of working.
I don't think there's much you can do about it. Either take the risk, or don't use off-shore contractors.
But I'd balance this with an honest assessment of how valuable your code is to you and to a supposedly dishonest contractor. If it is really valuable, then you should be able to afford to take legal action to protect it ... even in a difficult legal environment.
Well, if you don't trust your developers enough to let them work with your code, then don't hire them.
I don't see any way you can meaningfully limit their access to code without seriously impacting their productivity. Even if you could compile some of the code, it's very useful to have access to the full source to understand problems and bugs.
At any rate, you may be overestimating the threat: Most kinds of piracy would be possible even with the binary, and without the infrastructure and customers your company provides, the stolen code is probably not worth much.
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 10 years ago.
Myself and a friend have created a startup, but we are both software developers. We are quickly realizing that we are going to have to deal with and understand, all of the intricacies of business.
Are there any resources that can help us avoid common problems encountered by the non-business-savvy? How do you balance creating your product with maintaining realistic goals to reduce time-to-market.
It's like you need to take off your programmer hat and put on the business hat, and vice versa.
My software business was in a very, very small niche market centered on computer aided design of the magnetic layer in hard disk drives (www.micromagnetica.com - please note that I am in the process of closing down my business as the number of potential customers has shrunk to the point of making the business not viable. The web site reflects this point). I have been in business for 10 years and have done pretty well. My competition was a series of commercial and open source programs (mostly university or government sponsored), so, although the market was small, I was able to create a unique product that sold well.
Pitfalls:
Putting your needs above the customer - Customer comes first - always listen to your customer's needs and make sure your development follows their needs rather than yours. Every programmer has a list of things they want to learn or do. Don't use this list a guide for your development unless it solves an issue or helps create functionality that the customer wants/needs. This one point can make or break your company.
Not clarifying your business idea - Put together a business plan - it will help clarify what you are doing. Read the book, "The Art of the Start", by Guy Kawasaki to get the business perspective of starting a business. If you need money then you can use this to help secure financing from either angel investors or venture capitalists. Otherwise, it will help clarify what you are doing.
Not marketing yourself - Do this the following:
(a) Find a good name for your company and secure your domain name. Even though a bad choice for company name won't kill you (my first company was called "Euxine Technologies" and it doesn't get much worse than that), but my product sold itself and was not encumbered by the name.
(b) Put together a web site as soon as possible with a good description of your product. Google will eventually find you and traffic will start flowing to your site.
(c) As soon as you have a working prototype create a mechanism where potential enthusiastic customers can download it and start helping you find bugs. You can make this the full version with a limited time or a limited version with no time limit. I have done both and both work. Make sure that users know it is a beta (or alpha) version of the software. The most important part of creating the beta user relationship is they will ask for features that you did not think about and this could take development along an otherwise unforeseen (and lucrative) path. This will also give you a way to keep your hand on the pulse of potential users.
(d) If your product is applicable to a particular industry go to relevant conferences
(either get a booth or make contact with potential customers) and sell your product through demonstrations, flyers, and the distribution of free limited versions of your software on CD.
Not Branding yourself - come up with a logo that you will use to identify you and your product. This logo will show up on your web, your business stationary, and business cards.
Not Managing your money - initially there is going to be a long spell before the money starts coming in. Be very frugal with your seed money. The money will not start coming in the moment your deem the software is ready to sell. There could be a time-lag of at least a couple of months between when people show interest in your software and when the sale comes in. This will depend on how much your software costs. The more costly the software the longer the time-lag.
Once you start making sales, there will be seasonal variations in how much money comes in. Always try and keep at least 6 months worth of money in the bank to cover salary and operating costs.
Not knowing who your customers are - Once you start selling software, make sure you know who your customers are - they might be different from what you thought they were. When I started my software company, I thought my customers would be all R&D engineers who were doing research in magnetic layers. After a while it became clear that most of my users were the subset of this group that couldn't program, but understood the physics behind the software.
Not acting in a professional manner - When interacting with customers be professional - act and dress in a professional manner.
Creating a product because the technology is cool, rather than because there's a market.
Creating a product because you want it, rather than because there's a market.
Creating a website that lists the features of your product, rather than the benefits.
Assuming that advertising on Google AdWords will work for you.
"Build it and they will come."
The #1 rule of StartUp Club: Every startup should have both nerds and businessmen.
Most computer nerds don't know anything about how to run a business or market and sell a product. There should be at least one businessman at your top level (but watch them like a hawk, lest they steal away with the fruits of your labor :-).
Not understand/knowing who you are competing with.
Not understanding/knowing your target market.
Not including your customers in the design phase.
Not spending enough time gathering product requirements.
Spending too much time gathering product requirements (analysis paralysis).
Not enough marketing.
Have a strong team so you can trust the people you hire to do their job.
Be prepared to do whatever it takes to succeed (ethically of course).
Not having a direction (business plan).
Not having goals or having unreachable goals.
Not understanding cash flow. There are a vast number of profitable businesses who do not succeed because of clash flow issues. Just because you sold a 1000 units doesn't mean you can afford to pay your staff and or other expenses. As I have heard it before "Cash is king!"
These are just some things that might get in your way. I would recommend not only worying about the business side, but worry about what are reasons software projects fail. There are numerous books about how to collect requirements, produce quality code, testing code (e.g. TDD), project methodolgies (e.g. XP, Agile, ...), and many more topics.
Your startup will likely fail if you can't deliver a product or if you can't deliver a product that doesn't solve the problem.
Finally, it is hard to judge success if you don't define what it means to succeed. Is it staying in business, doubling your revenue in 1 year, breaking the $250,000 mark, or doubling your staff size. You need to define what it means to succeed not only in your business, but with each product you create.
Do your homework. If you are in the US, the small business association is a good place to find resources.
Trying to be all things to all people.
Often in trying to create a product that appeals the everyone, the product becomes so general that really no one can get excited about it.
In my opinion, it's better to target your product to a niche community of people with a very specific need and then fill that need better than anyone else.
Here's a common pitfall, but it's not restricted to just small companies: Lack of diversity in the management. The kind of diversity that's important is diversity of experience. I've seen a couple small companies that suffered from this pitfall. They can often go along for a while making good decisions. The problem is that it's almost impossible for them to tell when they're making bad decisions. This doesn't necessarily mean that they'll fail, it just weakens them to varying degrees.
Company Development - in the software industry you can make a lot of money (respectively to other trades) in a very short-time. most people tend to get greedy and want more money so the accept more projects and hire lots of people - but they don't develop their infrastructure, their communication-lines, their responsibilities, their developers etc. Because it costs money and you don't have a direct benefit from it and you lose your cool "flat-hierarchy-everyone-is-a-boss"-image (which is not the case anyhow)
I myself witnessed two promising start-ups fail because the grew way too fast.
So keep an eye on that one.
Shiny! Don't let developers chase the latest shiny thing on the internet that catches their attention. Keep developers focused on the core strategic needs of the company instead of steering your product in different directions as their interest is caught by other things.
There's a blog full of tips at OnStartups. A few recent, relevant posts: learn from the underpants gnomes: have a business model, and here are some marketing tips. The author is a developer-entrepreneur himself, which sounds like exactly your perspective.
Update: Dharmesh just set up a StackOverflow-powered site for just this sort of question: http://answers.onstartups.com/
Make sure you know your target users and their needs.
I worked in a really cool startup where we thought we had a great product, but we were unable to generate that great user story to really demonstrate how our product filled some need for them. This shortcoming prevented them from "connecting" with our product in an exciting way.
In my opinion, the disconnect was due to the fact that we didn't know our target users and understand their problems as well as we should have.
Sales Sales and More Sales. Plus a willingness to release before the code is "perfect" and release features incrementally. There is actually a pretty good Hanselminutes about this very topic and this very site (http://www.hanselminutes.com/default.aspx?showID=152)
Not having some people on the team with different ideas/backgrounds/personalities.
If everyone is always agreeing with each other all the time, and there isn't any friction, you aren't going to get anything done. Oh, you might be alright for a while, but if everyone thinks the same way, when you get stuck (and you will), you will stay stuck. When you're on a roll, a curveball is a distraction; when you're stuck in a rut, or up against a wall, a curveball can get you moving in a different direction. It might be the wrong direction, but at least it's a direction.
Not having enough knowledge and experience in marketing. Although selling a good product is easy.
The problem is what I call IBM OS 2- geniuses build a very good product but the product is not marketed well nor tailored to effectively massage the ears of buyers. I despise some things about business workers like short-term thinkings, perfering quick-and-dirty developers over slow-but-great developers and other issues- but they are the ones who make money and drive software into customers' hands. If a start-up does not have developers who can function effectively work with business issues- then it need to go get someone who can. Failure to do so make is what made Windows 95 a hit and IBM's OS 2 a dinosaur.
Not having a specific market in mind when developing a product. A couple of places where I worked tried to do anything and everything which lead to not enough effort on one market to get profitable first so the business could still be running.
Micro ISV links has some links that were shown in a top secret presentation I attended a little while back that may also be useful.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Do you find that corporate buzzwords or heavy management jargon gets in the way of software project communication? for example using words such as
Mainstreaming
Holistic
Contestability
Synergies
etc.
Would you rather see a initiative within the industry to put a stop to jargon such as this to help people communicate better and keep project communication in plain English? Is it even a problem? What are your thoughts/anecdotes?
I actually like buzzwords, when they are used in moderation.
They became buzzwords for a practical reason: Even though the concepts may be very complex and/or abstract, there is a consensus on the meaning. So with only one word, you can convey a whole lot of information to a large group of people. I see it as a form of encapsulation of information.
(Notice the use of the slightly outdated buzzword encapsulation?)
Of course, that is exactly the reason why many people start to abuse them: They only convey the general concept (i.e. why it's great to do FizzBuzz), and avoid discussing the messy details (i.e. why it won't work).
And since using a buzzword gives the impression that you are deeply familiar with the subject at hand, it can be used to silence others in the discussion.
Conclusion:
Buzzwords are ok - if they are used in the right way. If you want to improve your team communication, train them in the proper use of buzzwords.
I think some kind of industry-wide initiative would be impractical as jargon is in the eye of the beholder.
I think all you can do is make sure that you don't use buzzwords yourself even when communicating with people who do. For example, use the word "people" when talking to a Project Manager who refers to you and your colleagues as "resources".
The use of technical language can both help and hinder project team's progress, depending on appropriateness.
First it's necessary to point out that what is considered "too technical" depends purely on perspective. "Mainstreaming" is as much of a technical term, as SSD, CORBA and SOAP. Something that sounds as jargon nonsense to one person is actually a shortcut to communicate a complex concept for another.
Software development as a rule is cross-domain activity involving in addition to the software knowledge one or more technical user domains. It is a big mistake to assume that sales, marketing, management and banking (just to name a few fields often incorrectly considered "non-technical") haven’t developed and advanced their own complex body of knowledge, in other word — technology: sales technology, marketing technology, management technology and banking technology.
And it’s project manager’s responsibility to facilitate productive communication between representatives of different technical domains. Some suggestions:
Make handy a project dictionary that can be accessed and updated by everyone involved.
Ensure that common denominator language used for cross-domain documentation (i.e. functional specs).
Introduce domain specific terms only when necessary, but then always provide a brief explanation of the meaning (don’t “build from scratch” —leverage the wealth of online encyclopaedias by linking where possible).
Make sure that there is common understanding amongst the project team of the key terms.
Remember that what is considered “technical” depends purely on perspective and you need to facilitate communication in all directions, not just one-way (which is often from software developers to business users).
At the end the software will have to work in the realm of users and you have to make a judgement on how much the UI will rely on specific domain language (this is going to be a trade off between easiness-to-learn and usage-efficiency).
Technical jargon (ORM, TDD etc.) makes one's speech more precise. Corporate buzzwords (aka management jargon), on the other hand, are designed to be able to express vague ideas when full information is not available.
As such, management jargon serves its purpose pretty well, in the sense that it does allow managers to effectively communicate about thins they have very limited understanding of. That said, good manager knows when NOT use the jargon, such as when talking with developers, or with executives, both of whom hate bullshit.
Based on the above, the (Anti-)Buzzword Movement, should rather increase awareness of the proper usage and application of management jargon, and encourage proper information encapsulation only with appropriate auditory.
Personally, I think that the jargon should be used more. I see this occurring more and more and IT people want to simply hide behind the technical elements of the world and act like it is completely the business folks responsibility to speak more geeky.
I'll be honest, speaking more GEEK is not something that the business people can do and you should not want that to occur. Learn the jargon. Become one with the jargon. Own the jargon. Then the next time you are discussing things, you'll not be back pedaling.
Take ownership of the business terms and apply them to the technical side of things...
What's wrong with "holistic" or "synergy"? These are normal plain English words.
Every field has it's own jargon, and that must tell us something - people like having special words, phrases or assigning special meanings to existing words that are only relevant within their own field. I suspect if we went back to the pyramids, there'd be a full set of architectural and building phrases that your average Egyptian just wouldn't understand. So banning jargon just wont work, creating an FAQ and glossary normally do the trick.
BTW This must be a case of pots and kettles. Does anyone outside IT think phrases like - "...We'll use an ORM, and then WCF will talk over HTTPS, throw in a bit of AJAX and some clever CSS on the client and we're laughing ..."
Absolutely. Since managers only talk in general, and we as developers want to understand the precise meaning. I personally fall asleep trying to read abstract writing filled with buzzwords.
The worst being SOA. Neither academic folks nor managers understand it though both use it extensively.
I can't stand buzzwords. One person's "encapsulation" is another's Orwellian destruction of language. Buzwords appeal to the same people who like "decks" rather than memos. For something to act as a representation of many possible things [e.g. "leveraging resources" can mean pretty well anything from using double-sided printing options to drafting people for the Army] there is necessarily going to be a dilution of meaning. If a senior lawyer in my firm were to ask me to "leverage the resources, then run it up the flagpole to get the ducks in line", I'd know that he was tossing back the Johnny Walker at lunch.
Conversely, if I were to respond to a senior partner's memo request with emtpy catch phrases such as those above, I'd be fired on the spot for being an idiot - and rightly so. Too bad the rest of the white collar world isn't like that.
Grouchy Old-fashioned Gen X'r
I'm OK with buzzwords so long as all the stakeholders (see what I did there?) are clear on the shared meaning of each word/phrase.
In general I think that buzzwords are good when used for encapsulating ideas and concepts. it simplifies communication between people who understand the words. However, I draw the line when people use a buzzword when a perfectly normal word would do. I know someone that will say they were "On an Audio" when they mean phone calls or say "dialogging" instead of talking. It makes me want to hit them. Hard!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I have a challenge I need some input on.
I am currently recruiting programmers for a new development department. I am looking for people that are brilliant at their work – so brilliant that they might “lack” some other things that I normally would require them to have (e.g. speaking Norwegian and (to be honest) – social skills in order to be able to meet the customer (I’ve worked with several of them before :) )).
My issue is in regards to communication between the client (customer) and the development team.
Background: We have a strategy of becoming our customers extended development department over the next two years. E.g. they consider us as their own department just sitting somewhere else. While we are on our way towards this target, we will have to make money on smaller projects. The work is there, so I am not afraid that we will not manage to stay alive.
But – we all know that good communication with the customer is one of the key elements on providing the customer with what they actually want (we are scrumming by the way) instead of something else. How do I manage to do this with people that do not speak the language, or again, does not even have the skills to communicate with the customer (you all know someone very bright that is going into deep technical issues with a customer that hardly knows the difference between Firefox & Opera)?
I have landed on a solution where I will be the interface towards the customer, the customer will join in on planning sessions, etc., and where the team will still do the demo. But in regards to continuous communication (daily) between the dev team and the customer, I will be the one doing the comms.
I know that this is not the optimal solution – being a middle man a lot of information can disappear between the customer, me and the team. Have anyone been in a similar situation?
Create a wiki. Create a page for your customer which contains pictures, business information, things to look out for, etc.
Have everyone contribute to the wiki, including the customer.
As time goes on, this page (or pages if you split the information on numerous pages) will allow
new developers to understand the customer faster
see the possible problems that may arise
your developers would contribute to the wiki since they have a tangible documentation where everyone can see how much they have contributed to the customer.
make the customer feel as if he is part of the development process
since the wiki is, by effect, a collaboration document, a common language will appear between everyone. It might not be the same as speaking your customer's language, but it will be a combination of your customer's and developer's language.
We've had a somewhat similar situation when we did "Beta programs" for select customers. When the customers had questions, they could only turn to the developers at that stage of the project because e.g. the helpdesk was not yet familiar with the new features.
We also used a "middle man" for doingt the communication with the customer and then passing it on to the developers, and this has worked quite well for us. What were the advantages? The customer alsways knew exactly whom to contact, the communication was consistent, some on the simpler questions could be answered without the need to "bug" the development team at all while some more difficult questions could be "boiled down" from a superfluous explanation to the real problem before handing the question over to the developers, both giving the developers more time to concentrate on what they do best.
Of course, if you want this to work, you'll have to make sure you pass on information between development and the customer in a timely manner, but I think it can be worth the effort (and in fact, our developers prefer it that way).
Communication skills are arguably more important than technical skills. A programmer that doesn't communicate well may well cause enough disruption to negate what they bring to the table technically.
Having said that, you still have to realize that not everyone is the best person to be "customer facing". You might designate one or more members of the team as liasons to your customers, and have the communication go through them when possible.
The developers should be shielded from the customers. Developers are usually hardcore technical people who eat C++ templates at breakfast. The customers are often very non-technical. A customer asking a badly formulated question on some trivial issue to the developer usually irritates the developer a lot causing at least a temporary loss of productivity. So it's better to have special paid people that work in between.
Don't underestimate the value of being in the same place. If communication skills are lacking, being able to point and say "look at this" can be far quicker and more effective than trying to explain everything in a meeting or email. But from "they consider us as their own department just sitting somewhere else" this doesn't sound like it is an option for you.
Generally I expect that at least some of your developers will be open to learning proper communication with the customer. Involve those developers with the communication (even if it's painful at first). English is a pretty universal language and your customer will probably be able and willing to speak it.
Shield the developers that DON'T want to communicate or learn to communicate with the customers. They may damage your relationship with the customer and you will damage your relationship with your employee.
Be careful about allowing written contact between the customer and your developers. Written communication often gets interpreted wrong, especially when written by people who do not have much experience writing carefully balanced e-mails, memos or letters.
As you build your relationship with your customer, you'll get to know eachother's personalities, and communication will be smoother.