

Are you lead / only developer in the company? What suggestions do you have? - panjaro

I&#x27;m moving into a non-IT company as the only developer. What are the do&#x27;s and dont&#x27;s? What suggestion would you give?
======
argimenes
This is both an amazing responsibility for you and a heavy responsibility. You
will have the opportunity -- perhaps for the only time in your working life --
to not only have complete control over the technical solution, but if you are
pro-active you may also have a say in the building the product, coming up with
ideas for features.

On the downside, you won't have access to any senior technical personnel in
the company to guide you or get you out of hot water. To mitigate this you
will need to invest heavily in your continued technical education, which could
mean buying learning materials or subscriptions to online courses and
tutorials; at least, it means taking the time to do things right, to research
thoroughly any new techniques or technologies you think the company needs.

While always striving to improve and to listen to your customers, you also
need to have confidence in yourself and your technical decisions. It doesn't
mean that you can't (or won't need to) compromise but it does mean projecting
a professional image of yourself to your colleagues and customers. Obviously,
the more you learn and the more experience you acquire, the more confidence
you can bring to the role.

At the end of the day, like with any job, you should be willing to pack up and
walk away if the situation becomes intolerable (as long as you leave things in
a professional state).

But don't forget -- you are in the position right now that most programmers
dream of. We started off wanting to just write programmes and build products
for people who had the confidence in us to just let us do our thing; but then
we found ourselves pidgeon-holed into roles predefined for us by IT
departments. A complete programmer is like a complete painter, he should have
a say in the product at all stages of its development. That means having the
freedom to not just cut code or write tests, but to influence the design, to
dream up new features, to have discussions about the marketing.

To an extent this role is YOURS to define. Have the courage to define it and
to enjoy defining it. It might be the last time in your career that you get to
do that, if you ever move on.

~~~
degorov
>A complete programmer is like a complete painter

Yeah, but it doesn't mean that one can draw classic marine art if company
needs manga. If the customer wants classic Windows app and you are interested
in mobile or web or VR or whatever - you have a problem. Of course, you can
create those C++ or Delphi apps at work then go home and spend your spare time
creating the coolest webapp ever, but it's extremely hard and unefficient.

------
thorin
Have you asked whether you can bring in another developer at some point?
Assuming your work is useful you don't want to support it 24/7 with no
holidays? I work for an engineering company and came in as the 2nd developer.
Over the years I've brought in many short and long term staff which has been a
great learning opportunity. It takes a special sort of guy to be a one man
team long term and is not for me.

~~~
panjaro
The goal is to build an IT team slowly..

------
zerr
I have an opposite question/concern - for many years I've been
senior/lead/"irreplaceable"/etc.. person in many small shops (most of them
were IT though). Now I'm thinking to get a job in BigCo - but I have that gut
feeling/concern - I'll be just yet another cog in the wheel. How do you handle
such feelings?

~~~
panjaro
I guess you get back to senior/lead/"irreplaceable"/etc..

------
Kmaschta
If I have to give you one advice it's to be or become good at explaining.

It's really hard to persuade your collaborators of your competencies,
especially in the case of no-techs more if there is your boss or for a
critical decision.

You'll become the king of metaphors!

~~~
BWStearns
Definitely agree. Though a warning, when convenient some people will
overstretch metaphors and then hold you to the irrational conclusion. As some
consolation, they would hold you to the irrational with or without the
metaphor.

------
degorov
My suggestion is not to do it. You will want to get back to IT industry, but
it will be rather hard to do if you don't spend tons of spare time acquiring
needed knowledge and skills, which is not so easy especially after 30. Source:
worked for 7 years as the only developer in a non-IT company (oil and gas
industry). The company had a sort of IT-department but 3 persons working there
were busy reinstalling Windows, printers, PBXes, LAN, support and so on. I
worked at R&D department with engineers and designers.

------
BWStearns
I've done this a couple times, and I would largely say don't do it since how
terrible your environment becomes is largely dependent on things that are
basically impossible to assess before starting.

The first time I was very junior but the programs that needed writing were
mostly data crunching stuff or super simple rails apps that was simply a way
to speed up the rest of the office. The company's core business was not in
software and the fact that they could produce helpful code in house on demand
was more of an added bonus. I also had experience with our domain so I was
able to help out on non-coding issues when needed, as well as spot where a
program could be helpful.

There were issues, though luckily I was able to work through with the
management. The biggest is that as the sole dev in a non-dev shop you
(assuming you show value after a couple projects) have a lot of people at the
company giving you projects and this will likely outstrip your personal
bandwidth. This can lead to feeling like you have n bosses where n is the
population of the company minus one. The trick here is to get good at saying
no as well as getting someone who is _actually_ your boss and getting them to
let you use them as a shield. The other problem is that you will probably run
into estimate problems. Software estimates are frustratingly inaccurate when
you're dealing with other devs, it gets much harder to explain to non-devs why
"this little feature" is actually not so simple. The only thing that can help
you here are your communication skills and other people's
understanding/respect. Pad your estimates, if something _really_ needs to get
done wicked fast they'll let you know, otherwise just nicely surprise them
getting it done early.

The second time I did it was terrible. The company was trying to develop a
product that monitored sensor data and said it was going to expand the
technical team. They also told me I could manage the technical project aspects
myself since there weren't any other technical people.

Coworkers would pop in at least three times an hour to ask for help with
Office or GoogleSomething or their phone, despite me reminding them that a)
I'm not tech support, b) it's impossible to program if you're getting pulled
away from your desk every 15-20 minutes. I was told that someone had met a
programmer who could and so I should be able to.

My boss constantly was changing the requirements of the project as well as
giving me "smaller projects" that weren't a part of the actual product. He
would then be upset that despite working on Project F for two weeks we had
made no progress on Project A for a whole two weeks! At one point the CEO
demanded that I used a certain technology I had no experience using he got
upset when I told him I had to devote some time to learning it.

Like any job these issues will largely depend on your coworkers and your
boss(es), so YMMV but in my experience these issues are encouraged by the 1
techie vs n non-techies environment. Try to head off any of these issues early
because if you let them get bad they will get intolerable.

