Hacker News new | comments | show | ask | jobs | submit login
First programming job – a 4 month reflection (pastebin.com)
37 points by _RPM 1311 days ago | hide | past | web | 68 comments | favorite



All work environments are absolutely not like that. I've worked in places exactly like that and places nothing like that.

I'm pretty sure it depends largely on the type of business. Businesses where software makes them money tend to have high code quality and developers that care about that sort of thing. Businesses where software (or IT as they'll call it) is a cost center tend to be like you described.

I'm also pretty sure there is a strong correlation between PHP and that type of environment. It's much less common with places that use Ruby/Python/etc. Probably for the reasons Paul Graham wrote about with Python vs Java: http://www.paulgraham.com/pypar.html


That correlation is exactly my experience.

What are examples of companies that have a verifiable 'great software' culture and chose PHP because they prefer the language?


The minute you stop thinking about "they" and start thinking about "us", there is a chance. If you just walk around thinking and knowing things are sour but are not going to do anything about it - guess what. Nothing is going to change. But if you take the lead, sell your ideas, execute upon the change, you will see daylight one day.

Most engineers never exit the "whining" phase though. But those who do, make a truly good mate to work with.


Thinking about 'us' is definitely the best thing to do and it is definitely a failing of (some) young but talented programmers to develop a certain arrogance which only puts others off.

However, at some point it will become obvious that you can/can't effect change in a meaningful timeframe. And if the latter, you should move on.

The sad truth is that often the bad type of programmers the author describes are unwilling to learn, and are especially reluctant to take lessons from a new/young colleague.


it's easier to just quit and look for a better job. it's the engineer's solution. what you suggest is a challenge to improve your soft skills. it's probably worth it but it's not for everyone.


I think a compromise is more constructive: fix as much as you can in a given period, and then find a better job. Apparently a 4 month programming stint doesn't lookt that good in a CV.


> I always prioritize security as number 1.

> I've made sure that my code was secure

> has just always been embedded into my programming philosophy

> So their environment was broken to me.

> I've began to realize that I'm a much better programmer than all of them

Good code quality, and security, is something everyone needs a bit more of, but be careful not to fall into dogmatic thinking. They are paying you to do tasks the way they want them done. If you can show them a "better"[1] way they might take your advice, but you should never expect it. Programming is more than just a job skill to me, so I always have to remind myself about the line between "my code", built on my own time, and "their code" for which I am being paid to build/maintain.[2]

> I showed them OSWAP, and they have never heard of it.

> I mentioned MVC pattern, and the manager didn't know what that was.

This is common. Never hearing of something is not bad. No one can keep track of all the tools available, learn them well enough to use them, and still accomplish what they need to do. No matter how much time you spend trying to keep up, you won't.

Also, your coworkers, and manager, might already know what will and won't be approved. So, they are only informing themselves of things that are likely to be important to their tasks.

> I've began wondering if all work environments are like this.

No comment.

[1] There are many definitions of better. (Time, money, complexity, maintenance, ROI, etc.)

[2] Some managers / employers want you to mix the two concepts, but, in my experience, this is just encouragement to focus more attention on the tasks they are giving you. You need to draw a line.


> They are paying you to do tasks the way they want them done.

Maybe with respect to "code quality", but it would be unethical write code with blatant security flaws, even if the organization paying you says "that's just the way we do it here".


Okay, it's clear that sooner or later you are going to outgrow this place.

But, just some advice for you in the meantime: don't be that developer who insists on your standards, no matter how much you feel yourself to be right. If you do that, you're going to be miserable and you won't get a good reference for the next job.

But more importantly, you should take this opportunity to learn about everything in the job that isn't coding. Like teamwork, communication, respect.

Success at the job is not about doing what's right in an abstract sense; it's about doing things that decision makers perceive as valuable. If you feel strongly that they're doing the wrong thing, then you're first going to have to change what they perceive as valuable.

In your programming career, you will often be employed by people who are less mentally agile than yourself. But you're going to have to learn to respect what they know and do well - understand the customer, forge relationships. Computers are so fucking efficient these days that even naive solutions have a lot of value sometimes, so deal with it. (There's always some other programmer who would be appalled at the shortcuts you take; you're not special.)

TL;DR: If you want respect, you have to give respect first.


I forgot to add that my manager might be cosidered a "micro-manager", I've heard him tell other developers that they should change a single variable name. and re-commit.

Another thing that I've noticed, and that has happened > 1 time is that I'll write something, spend like all day on it, then come to work the next day to have found out that the manager re-wrote it claiming "simplification" of the code, which is in fact not true, or claiming my code had a "bug" These bugs aren't security bugs, or anything for that matter. Their small user permission things that I was never told about and is not documented. I don't care if I can't work on something, but if you want to do it, then do it, don't ask me to do it, then re-write it because I could have been working on something else in that time.


> I've heard him tell other developers that they should change a single variable name.

That is totally legit, if there is a naming convention in place on the project and the developer violated it. If it's just his personal caprice, then yeah it's dubious, but better an idiosyncratic dictator than no standards at all.

> then come to work the next day to have found out that the manager re-wrote it claiming "simplification" of the code, which is in fact not true

This is extremely common. You've already documented how this shop has no good procedures, so people waste a lot of their time rewriting stuff.

I hate jobs where I have to be someone else's extra hands. It's a sign of poor organization on every level.

That said - I hope as an open source programmer you've learned not to get attached to your code.


That is part of life though, and as frustrating as it is, you'll sometimes have to expect that other people will rework your code.


It is, but it's definitely not a good way to treat new people to the team, especially people on their first job.

Much better to explain the bug/problem and let them fix it.


Very true, again highlighting some of the flaws of OPs current workplace.


My first web dev job was a university as well. Department by department can be different but it is not a normal place to work. If you are gunho about ramping up your skills and getting into the industry I would suggest not staying long. The attitude you have now and any drive you have to make things better is hard to sustain in an beurocratic environment like a university for long, especially when they don't seem to care. However! If you are young and have visions of traveling a lot in your 20s and experiencing other parts of life then very much work there. You will probably never work over time, get things like 4 - 5 weeks paid vacation and be allowed to take them off all at once on little notice.


> One file has 3000 lines of code, and is a huge switch() statement.

Kids these days. I once worked on a system where the size of the switch statement broke the compiler. I believe the limit was 64k lines in a switch, although my memory is a little hazy. Of course you couldn't actually reasonably edit a single file with that much code, so it was split into several files, each of which was still thousands of lines long, but at least you could load the smaller files without crashing emacs with out-of-memory errors.

  switch (action)
  {
  #include <actionsetA.cpp>
  #include <actionsetB.cpp>
  #include <actionsetC.cpp>
  // etc
  default: printf("unhandled action")
  }


No, that did not ever happen. I reject to believe. Oh my god, how frightening is this!


There's a whole site full of stuff like this: http://thedailywtf.com/


There is always politics in any workplace, any organization.

My first thought is to have meetings where you and your team make a list of problems that you guys are facing (is logging not enough? is disk filling up quickly? is it getting hard to maintain some part of the code, etc). Don't go overboard. People who are much more senior than you are in this organization have pride. Imagine you worked your way up and did most of the coding and suddenly a new hire called your code shitty and ugly and non-functional, that hurt. Also, some people fear of breaking system. School in particular hates it. They don't care; students don't care. If school's portal is down for more than 1 hour, someone is gonna get an ugly call from some executive admin.

I can say testing, MVC patterns, all that shit (excuse my french here, in your manager's hypothetical voice) are least priority. What are your priority. Prove SQLi. Then fix it. Are there documentations for how to set up a server running the software you guys are working on? Is it done with a shell script. If so, is it working?

Testing and new development patterns shouldn't be your priority. They are cultural. You can't build Rome in one day unless you have all the people behind your back.

Scrum style, sure, but do it slowly. Also, this may sound extreme, but sometimes, you need to play a bit dumb. Don't show off. Some people can't face the fact they are out of the league... sometimes playing dumb/doing things a little slow can make things smoother.


I care about code more than most people

I get the impression that this guy thinks of himself as "a coder". He wants to write code all day long. He wants to write the best code in the world. He wants to write code that's robust and tested and modern and secure and clever...

...and all for the sake of writing code that's interesting to him.

In the real world we have to write code that enables users to do things. That's it. Usually that also means writing code that's tested, secure, robust and so on, but for the sole purpose of making users better able to use our software.

We write things that are secure so that users don't lose their data/privacy/money.

We write things that are tested so that users don't face errors and bugs when they use our software.

We write things that are robust so that users can use our software whenever they need it without it falling over all the time.

If I was the manager of his team and he came to me suggesting "Dependency injection of the database objection into a class" I'd say no too without a good reason - the entire team would need to learn the new code, any code that relies on the old system would need refactors, and so on. But if he came to me and said "If we used an injection pattern we'd be better able to switch to a failover server, we'd be able to add features faster and it'd enable use to use a better security model", I would listen.

A big part of development is actually "sales" - if you can't sell your ideas to your team, you'll not get to implement them, even if they're the right way to do things.


That is very similar to my first job. The truth is that most programmers are not very good at writing software. Some don't care about code quality, and others haven't learnt (yet) how to program well.

When you apply for your next job be careful to ask about their coding practices. Ideally you should be able to find their lead devs on github or somesuch and view their code to get a sense of how good their work is.


I've seen a lot of this in small organisations. Typically they are isolated from the rest of the developer community.

Your challenge, if you choose to accept it, is to hack the social environment: get them all slowly to come to meetups and hackdays and stuff and engage with the rest of the industry. They'll hear the buzzwords and learn, and change will happen. It will take a while...


I think it's less about the skill and more about the development process. When your manager comes to you and want feature upon feature added to an existing project that once was written without any basic requirements laid down, the code is going to turn to shit pretty quickly and nobody is going to care about it. The process is broken.

One of the reasons why open source is good is because you associate your code with your name. You take personal responsibilith for it. At a company where developers have come and gone over time, that doesn't happen.

Now, how you approach this matters. You can either become one of those who don't care, you can start to roll the stone uphill or you can seek greener pastures. It's all up to you. The people you work with sound like they don't care for things as long as it works. Do you want to become like that?


I've been there years ago where OP is now. I can tell him this: you've only scratched the surface. Just as there are very good programmers there are also very bad ones. Trying to make a bad programmer into a good one often ends up in a catch 22 - he would already be a good one if not for all the constants in equation that makes him a bad one. My advice number 1 is this: move on, find a team of solid professionals. Advice number 2: dump PHP, learn a more serious language like Java, Scala, Clojure or C/C++ if a lower level is in your interest. It just so happens that often guys who work with those languages tend to be better than guys who work with PHP.


It feels so bad to rag on PHP. I mean, it has myriad sins against man and nature, but so do most languages. But its central ethos of "make programming democratic" has managed to create a community of mediocrity. Obviously there's always the valid rejoinder "every language have good and bad programmers," but the tolerance and even the generation of the bad is so much higher in PHP.

To the author of the article: move higher. Whenever you feel like you're in the top third of programmers at the place you work, it's time to move on.


Correct me if I'm wrong but neither Java, Scala, Clojure, nor C/C++ tend to be used for web development, right? So OP wouldn't be doing web development if he picked those up? From what it sounds like, OP is doing web development, so maybe some other suggestions such as RoR, Node, or .NET etc would be more applicable?


Java is used a lot in web dev. See servlets and J2EE. It can feel a bit enterprisey though.

Scala and Clojure are relatively new languages but they have pretty good web frameworks, which tend to be closer to RoR than the J2EE stuff.

C/C++ is indeed used very rarely - it's just too dangerous and unwieldy.


Well, I have to thank you, I have learnt something today and I've only been awake a few hours. I did do a quick bit of research before posting my comment, to make sure I wasn't overshooting the mark, but I didn't see anything about Scala/Clojure web frameworks, so on that regard, thank you for enlightening me.

OP should definitely move away from PHP though.


I recommend learning JavaScript for web (backend) development. In fact, the OP already knows it.


Dumping PHP to use JavaScript instead? That's like moving from terrible to terrible ...


No, JavaScript is a great language if you just use the good parts[1].

1. https://www.youtube.com/watch?v=hQVTIJBZook


That's exactly what defenders of PHP say, too.

Can we just stop pretending that a language cobbled together in 10 days has good parts except by chance?


If you strip out the good parts of PHP, you're not left with a good language. With JavaScript you do. That's why modern languages are copying JavaScript's killer features, like anonymous functions and closures.

In addition, the language wasn't developed in 10 days. It's first design was. And it borrowed from earlier languages.


> That's why modern languages are copying JavaScript's killer features, like anonymous functions and closures.

LOOOL. You're joking, right? On which planet do you live?


I'm not joking. I'm living in Earth.


It is always easy to complain but you never know how all this evolved. Maybe the founder had hard times to find the first developer. Maybe the first developer could not do it better. Maybe this setup only attracted weaker developers and suddenly this mess was set in stone. Maybe the business model doesn't provide enough margin to justify a rewrite of large parts of the legacy code and so on.

And I could also easy complain about you: why did you choose this aged stack for your first programming job in 2014? This stack is still very popular and nothing bad but yeah, there must be some reasons why you chose this stack which I don't know.

But I won't complain.


Sorry if I am a bit late to the party. I am a student right now and this is one of the issues that's freaking me out about working in the industry. I'm genuinely scared my code is not up to par, have no ideas what security issues I should take care of to start with and also how the hell am I supposed to cover all test cases with TDD? I am alright with following design patterns and ensuring clean documented code but am always under the impression I can do better. If anyone has any insights, would be really grateful, especially when it somes to security.


As you go through your career it will only get worse like this before it gets better. Normally when it gets truly better is around the point that you start your own business.


Yep, lots of workplaces are like this. As you do care, get away from PHP ASAP.

Beware of structuring and refactoring too much, or writing low-ROI tests. You must find balance.


While I dislike programming in PHP (the syntax is ugly mostly), and I like Python and JS, I don't think getting away from PHP is a solution and the solution. PHP is not the problem in this situation. It's the people who is working there with OP.


I like to think that's what lalc was implying. With a language comes community, and PHP's community is unfortunately laden with baggage.


Okay. That's a fair point. Maybe it is right that people have to leave their territory once and feel the difference in another community.


This is what a lot of it is about, balance. When we write open source software, we don't usually have costs, time isn't a factor, we aren't being rushed by a long todo list, so we can invest in the code. In business, we don't always have this luxury.


The place I just finished working at employed people to manually run regression tests on HTML forms... I implemented an automated system using selenium and Jenkins which ended up mostly working. I say "mostly" because Selenium itself is kind of flaky (I had a read, and wasn't impressed) and there's a lot of crazy stuff going on with the web drivers. Next time I think I'll use Phantom JS.

I feel it, OP.


It's always sunny outside - a 1 minute reflection

Seriously though how can you start generalizing / assuming about working as a professional programmer when you're not even 1 year into your first job?

Try your best to change things, but don't try your best for too long till you burn out and are miserable. Some programming jobs are there just to separate the wheat from the chaff.


This kind of stuff makes me feel...I'm not even sure how to qualify it. I feel like a lot of places that hire set these great and tall expectations that always make me second guess myself. Do I have the skills and know-how to do this?

How was your interview process in comparison to the quality of people you're working with now?


If you want to be/work with engineers and build something real/hard, I would start looking for your next job. Even without professional experience, don't settle, find a place where the standards are up to yours.

(We're looking for engineers at my company if you're interested..)


Type in 'ruby-lang.org' and get redirected to the https site where you find 'security' as a main menu entry. There you find known issues and ways to report vulns.

Try this on php.net.

[Edit: I tried to download the stable php release via https. Try to guess how that worked out]


your coworkers are people who are in this job to get paid. you're probably programming because you like programming. learn some other language and search for an employer who cares about the same stuff as you do - you'll be both better off.


"your coworkers are people who are in this job to get paid. you're probably programming because you like programming. "

You know, I have a sneaking suspicion that every programmer thinks this way.


Definitely not every. There are people who do it themselves just as a job, and are self-aware of that.


I've worked at a total of 3 companies over the course of 5 years. 2 of those 3 companies I've worked for have no coding standards at all, which is surprising because the company is able to make money despite the quality of code.


Why does that come as a surprise to most people? Businesses don't care how their code looks - if it works, it's good enough.

Which is also why changes are discouraged - no need to mess with something that works unless absolutely necessary.

Not the best policy, but if it works - it works :-).


It definitely depends on a lot of factors.

Even if they don't have any formal coding standards, a company can ship good products as long as they have at least a few decent programmers.

Ad hoc / beta testing can fill in for unit testing. Bad coding style and low modularity won't necessarily make a project slower or worse, just harder to maintain. Lack of version control isn't necessarily a major problem if there are daily backups of source code, and if each part of the system is being developed by only one person.

No tech company or startup would ever consider things like that sane practices, but many companies do get away with it. Especially if what they're programming isn't the company's primary product or service, like in the case of a university.


I learned this the hard way. I am the sole developer at the company I work for. I write code for 10 different web products. One of them receives inventory feeds from a myriad of different content providers, and most of these companies (with teams of developers) don't really know the first thing about proper xml design. I wrote a basic framework to do the bulk of the work for consuming their data, but the decisions they made run the gamut from just plain laziness to utter incompetence. Still, I'm not paid to critique their decision making process. I get paid to write the code that makes their data work with our system.


Again performance and security improvements come in at later stage when the business wants the systems to be more cost-effective and performant.


Welcome to the real world. Where code is not perfect, but somebody pays for a timeboxed piece of work and legacy code will exist.

You will not come into heaven straight from university and you will have to learn to work in environments like this.

Blame your study for not telling you about how the real world works. Don't blame legacy code because it's something that exist no matter how unicorny the world is.

Negotiating managers and project owners is even more important than just being able to write testable code.

So take your skills and apply them (iteratively) to your current job, or go work at a startup where everything is hip and trendy. But remember you're at the bottom of the ladder right now, and you're the one making things better for companies and yourself.

Also remember the golden rule:

No one wants to pay to refactor code that works into more beautiful code that works.


WTF I get downvoted for this?

Why am I even here.


"I've began wondering if all work environments are like this."

Yep, it's pretty common (and sad).


Common among government agencies and universities, sure. Fortune 500 companies? Some, but not most. Tech companies? Not so much.


Small webshops are also rife with this kind of programming environment. Mostly because their clients have no idea about code quality and the projects are small enough that you can still just about be productive with terrible programming standards.


And from what I've heard, bad practices are more common in PHP shops.


It's so funny, i first thought i wrote this. Im in the same spot at my new workplace.


Hello, I am you from the future. You are in for a treat. Buckle up.


welcome to the NBA

and no, it doesn't make you a better programmer.


What does NBA mean?


National Basketball Association. this should explain: http://allball.blogs.nba.com/2013/11/13/welcome-to-the-nba-j...


Want horror stories? Try consulting.




Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: