9

Just got my first jr web developer job and I am thrilled!! at least I was -

Basically the code has no documentation and the company has basically no sense of process. its me and about 5 other devs scattered across the globe, so meeting is sparse. The code was built by contractors we have no contact with anymore who all disappeared and most of my time is spent haphazardly attacking really difficult bugs. No unit testing or QA stuff.

The more senior devs I have talked to out of the work place laugh like crazy when I talk about all this but I am legitimately scared - How do I implement process at my first job when I only barely know what I am doing? Should I try to get out of here before I develop bad habits or is this a right of passage? (Ive only been here a few weeks, how long should I wait?) Management seems receptive to the feedback and seems to want to build the right processes and hire the right people, but they spend their time putting out fires and not much changes.

  • 2
    Can you clarify what you mean by "no process". What aspects of process are you missing, specifically? – meriton Jun 2 '17 at 23:37
  • Who is in charge and what does that person say; e.g. do you have a team leader or manager that can drive the direction? – Brandin Jun 3 '17 at 6:57
  • 2
    If management would care, things would be different, but hey, welcome to the real world. – Sascha Jun 3 '17 at 18:03
  • heh; the OP wisely changed to Anon :) :) – Fattie Jun 4 '17 at 12:49
  • "The code was built by contractors we have no contact with anymore who all disappeared ..." - That is what contractors do. To expect them to do otherwise is just foolish on your part. Do you expect your home builder to call you every quarter and ask how it's going? – Wesley Long Jun 5 '17 at 15:42
14

How do I implement process at my first job when I only barely know what I am doing?

Implementing processes requires authority, which is generally held by management. You'd need management's active support, but it would be very weird if you, a junior developer without neither much experience nor reputation in the company, were given such power.

All you can realistically hope for is make suggestions in the right ears, but again, this will only work if the person in question is receptive, which generally requires building some trust first. Of course, if they actually ask for suggestions, go ahead and prepare some, but otherwise the most likely result is annoying busy people that have much influence over your future career.

Should I try to get out of here before I develop bad habits or is this a right of passage? (Ive only been here a few weeks, how long should I wait?)

First, on all but the smallest of companies process changes take months, not weeks, to fully implement, in particular if the management team is kept busy by other things.

As for developing bad habits, I am not convinced you would. After all, you seem aware their process is bad, and aware of the damage it causes. In contrast, seeing such consequences illustrated vividly on a daily basis seems a great way to learn what to never do :-)

One of my first jobs featured a technical lead that had some very particular failings. I suffered from them, and learned what to never do if I ever became lead. When I was promoted years later to a technical leadership role, those memories helped me avoid mistakes I might otherwise have made. Or to put it differently: "nobody is useless: they can always serve as a bad example" :-)

But back to you: Being in a company with a bad process will teach you that this process is bad, but won't teach you a good process. So, if after a while process does not improve, it may be advisable to switch companies (and remember to ask about process in the interview, if you do).

In the meantime, there is another valuable skill you can learn in this company:

Basically the code has no documentation [...] most of my time is spent haphazardly attacking really difficult bugs

Tracking down bugs in undocumented code written by people no longer available for questions is a skill you will need many times in your career, because even the guys with 100% code coverage sometimes find the cause of a bug in sparsely documented library code written by other people.

So, should you stick around or leave? That depends on you, and numerous factors that are hard to communicate in a Q/A site. But personally, I see nothing in your post that would truly trouble me in the short term, so personally, I'd probably stick with this company for a year and then reassess the situation: Has process improved? Can I now learn the other things that make a developer or am I still stuck firefighting? Am I happy in my job?

The reason for waiting is that leaving a job after less than a month looks odd on a resume, so you'll only want to do this if necessary (your local cultural norms on this may vary, but such is the case where I live). The second reason is that they might come around, and improve process, giving you the opportunity to get a reputation for making good suggestions, which will help your career. And third, unlikely as it may seem, perhaps the process they use is not as dysfunctional it appears at first glance, and isn't limiting your career after all.

6

As someone on his first job and in a similar situation let me tell you that this isn't a right of passage. These are major red flags and indicative of bad engineering.

Lack of processes only make it hard to reason about code because people end up adding code willy nilly and releasing it to production. In the long run, the codebase becomes a giant hairball and difficult to deal with.

So how do you implement a process? You don't. It's the job of your manager to do so. Trying to implement one might feel like stepping on his toes. Raise this as an issue in your next team meeting and if he does create a process or asks you to create one - awesome. If not, don't push it further.

As for developing bad habits, that's something on a personal level. Make sure you know the best practices for your language / framework and try to incorporate those in the code you write. Also, familiarize yourself with literature on the same topic like "Clean Code" book, etc.

As an aside, if the code is hard to reason about then no amount of QA is going to help because bugs will end up slipping through your test suite. This I picked up from one of the talks by Rich Hickey, creator of Clojure programming language, on why software development needs to be simpler.

  • Agreed, but note that as I humorously explain, the solution is very simple: you just tell the boss a specific code debt suggestion. In one specific sentence. And leave it at that. ("Hey boss, if we remove column X from the schema it will make ABC much easier in the future. Should I do it?") And just keep doing so. – Fattie Jun 3 '17 at 17:11
  • 1
    As someone who's been writing software professionally since 1986, you're exactly right. It's not a rite of passage unless that rite is working for someplace that doesn't know what they're doing, which we all do at some point. Definitely red flags. – Chris E Jun 5 '17 at 15:31
  • 1
    @ChristopherEstep the problem lies in the glorification of the "startup culture". Like Robert Martin said, software does have older, more experienced programmers but it's become a young man's game. It was in one of his YouTube talks. – Little Child Jun 6 '17 at 12:04
  • 1
    @LittleChild There are tons of articles and talks that a startup culture which has adopted a lazy culture in terms of "process" (whether it's software or other operations) are destined to fail. Perhaps more would succeed if these entrepreneurs would educate themselves in the necessity of methodologies and structure. The startups that succeed with loose organization and no processes are the exception, I'd wager. – Chris E Jun 6 '17 at 13:25
4

Basically the code has no documentation

I have never, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever, ever seen code with documentation, and I've worked with all the software that you us every day of your life, on every continent, and most industries.

and the company has basically no sense of process

I have never, ever, ever, ever, ever, ever, ever, - etc - seen a software division or entity with a process1

As my first computer science professor mentioned, "If architects and builders were like software engineers, civilization would collapse by Tuesday."

Note!

Your comments mark you as a beginner!

I've just read on the rest of your post, and indeed just as you say "The more senior devs I have talked to out of the work place laugh like crazy..."

So, nothing more to say here; you've "discovered software"! Enjoy.

Don't again repeat this idea ("I've noticed we have no process or documentation! I can fix it!") to management, or anyone!

... rather, be specific.

Think it through tomorrow. On Monday, tell someone:

"Hey, I've spotted this {schema, API, class, whatever} where we have a lot of technical debt. I think with {N} days work I could dramatically {refactor, start over, use a BAAS, rewrite, whatever} and it would save us a huge amount of man-hours from then on."

So, congratulations on being "today's Obvious post" :) But the great news for your career here is that if you go with the ingenious "specific..." approach you'll be one of the senior guys laughing at the new guys, in no time! Enjoy.

Further tips when implementing the "specific..." approach:

  • in particular, the language "code debt" will really work for you here. explain that you have found some code debt and in a specific amount of time you will save a specific amount of future man-hours.

  • don't even hint at pointing fingers of blame. (If you think any one colleague, or entity in general, is responsible for the sewer that is software on this planet, that's just naive; don't even vaguely suggest blame-or-reason.) Just state in short words the system/line of code/whatever where you see technical debt.

  • in the second part of the formulation ("... and it would save us X man-hours from then on") be specific. So, "it would slash the man hours spent on {that particular web input form / these particular REST calls in the XYZ build / what Jeff's doing at the moment}"

  • Wish I could upvote one thousand times. Big rivers are made out of countless smaller streams. Add a stream everywhere you can. And read Joel Spolsky : joelonsoftware.com/2001/12/25/… – gazzz0x2z Jun 4 '17 at 12:31
  • lol thanks man @gazzz0x2z - just trying to be entertaining :) – Fattie Jun 4 '17 at 12:48
  • 1
    Hey @GabeSechan - think you were lucky :) I think the point is for the OP how to proceed: be specific and suggest a way (probably small to start) to unwind code debt. – Fattie Jun 4 '17 at 19:52
2

Sorry to hear that. It's difficult if you are an experienced developer, more difficult if this is your first job. I'm assuming that you are clever, and want this job as an opportunity to grow (so you start your next job as a not-junior-anymore).

I'd talk to your manager, and get his permission to spend a bit of time to document every bit of code that you had to look at and understand. And then every time you have to understand someone's code and spend an hour understanding it, you then spend 10 minutes adding documentation to it. Then the code will improve bit by bit. And the next time you have to understand the same code, it's much quicker.

  • I like this one because it takes a more proactive approach. If you don't slow down your productivity, I wouldn't bother asking (I'm more a risk-taker, though...), but step up and document as I go (I like the 10-minute idea). When I'm done with a major chunk of documentation, offer it to the boss or, better in my mind, to the team. – SliderBlackrose Jun 5 '17 at 15:31
2

OK. Let's even this up a bit.

As a junior developer, you're not there to be in a leadership role yet. You've identified already that you barely know what you're doing. How do you realistically expect others to take direction from you?

Still, it's good that you can sense that something's broken. Rather than overwhelming yourself with trying to change what the entire team is doing, you can focus on consistent results in the work product that comes from your desk alone. When you do that, you'll come to be known as a person turning out reliable, maintainable, and scalable code. When issues come up with others or bigger processes, then you have the opportunity to speak up and make suggestions. Until you have that kind of reputation, you need to lean back a bit.

None of these things gets fixed in a day. They've been messed up for a long time since before you showed up, and they might be the same when you get your next job - but you don't need to blow a gasket over the situation. Sometimes, you have to let people fall down before they become believers of the concept called "gravity"; you can explain, demand, urge until you're blue in the face, but no one will get it until they've fallen down and skinned their knees. Relax! One day at a time.

  • Sadly, in my experience, some people keep scrapping their knees but keep blaming the people who built that perfectly flat floor instead of learning how to walk. – leokhorn Aug 24 '17 at 13:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy