- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Is perseverance frustrated? Is the A team allowed to crush anyone who might threaten their aura of superiority? Is any existing documentation (even other developers' notes) jealously hoarded in secret? Is a new worker ridiculed or even penalized for asking questions? If so, then PYB is even as you say.
Or is perseverance rewarded? Has the A team been told to be on the alert for the rare gem? Are resources provided for the ambitious hungry talented? Is it possible (if difficult) to grow and progress? If so, then PYB is correct and is doing the best for his company overall.
There's a big difference between "frustrating, hindering, and exploiting" and "declining to offer to help".
-Harrow.
Admin
You know ive been at that crossroads before and you know what I did? said "fuk dis" and got into accounting. Now I'm pulling six figures a year and I've got more $$$wag than you can shake a stick at. do yourself a favor and blow off this chump change programming crap your going for and become an accountant too. if you dont want to do that you can do the next best thing and off urself, skrub. get rekt
alpha doggg
hoooouwwwwwwwwwwwwwwwwwwwwwwwwwwwwww~
(Captcha: Esse. Don't mess with me esse >;( )
Admin
Admin
Odd coincidence: I was listening to this about the same time you were entering it.
Admin
... and this too (the upper of the two) ... just so happens I was playing through all the songs on my mp3 player in alphabetical order and today I got up as far as W ...
Admin
I find it to be a little funny that the Library of Congress is always a benchmark to the amount of written volume. Similar to horse power in modern cars/ships/jets/space rockets. I've never even been to Library of Congress. Is that place real or only in a dumb Cage movie?
Admin
The truth is most of the arrogant pricks in IT know a lot less about what their users want than they make out. They big up 'complicated' stuff because they don't understand simple business rules and so write code where you can rip 95% out if they bothered to try to put themselves in an accountants, or sales, or client service employees shoes. This new wave of agile isn't helping either as it appears to drive the bottom performers to actually do something for a change but hampers talent because they aren't allowed to stray too far from a story, it makes developers who do not understand the domain implement requirements like brain dead robots, and because most are arrogant pricks they will not listen to advice. I love programming business solutions but dislike most of the dick heads in IT so work freelance now so I can spent my productivity with people who actually think about what people want/need (rather than what they asked for in their requirements doc) and have much more interesting and less bullsht filled days. For now my advice is find a job with the smallest team you can find so you don't get patronised for your first five years, and develop a relationship with your users and ask them about their job away from your system - you will be sure to find new avenues for software development but above all you are much less likely to end up as a self satisfied prick talking about Cobol.
Admin
Admin
I don't know... When I first joined a software house developing equitiy trading application, I know nothing about stock market.
Then I spend 3 months of my spare time to learn how to be a broker, and I started to go work. (Although I'll also lucky enough to have peers working on the same project, so in cases that I was not so sure, I can ask.)
If you ever need to work with a very domain-specific system, you should learn as if you need to become one of the users.
Specifications from PM and seniors won't always work because they usually won't go into too detailed part. You have to understand what you write to avoid making stupid mistakes.
Admin
As a team lead, I am often tempted to throw a new employee in at the deep end just like this... as a test.
As many other posters have said, these kinds of systems are huge, and the domain is full with jargon. Explaining the whole system would take three years of time from my best developer.
So, the test is to see if you're the kind of person who can pick one small problem, and figure out enough of that tiny corner of the application for yourself. What is your level of independent, self-training go-get-it-ness?
Admin
There is one more question: What do you really want in a long term perspective? The answer to that will have a big difference on your professional career.
To make live a little easier for you NOW, you should at least learn a little bit about the business domain. I met a lot of software guys working many years in the same company that didn't know even the simplest business terms.
But at some point in time you will realise that you can either try to be good in business or to be good in coding. Both domains are so huge, that you will not be able to be very good in both of them. If you want to be very good, you will have to decide. Otherwise you will remain average in both.
The path to business might lead you to be a good business analyst or maybe a good architect. If you are strong in comunication and like to work with people this might be the way to go. If you are good at it you are visible in the company and might be solved as a problem solver. But you will lose the grip on "high end" software development.
The path to software will never give you the details of the business and you will have to live with never having a deep understanding the business. You might never be really visible to the rest of the company. But also it might be more easy for you to move to a completely different company. Technology is technology. And you have the chance to become very good at it.
It all depends on where you put your heart into!
Martin
Admin
Excellent article, sound advice. Well done! Hard to find a common-sense read in SEO optimized sites these days...
Admin
To me, the problem described in the OP is one of the biggest WTFs in the business.
I get that I may not understand everything, but how many times have you thought a requirement looked a bit spurious and queried it, only to get to a business analyst, or someone in the business whose only answer is 'I dont know' or 'Its always been that way'.
I find that point incredibly frustrating as its just their laziness creating more work for people down the line. I can think of loads of occasions where I've chased requirements further only to find that its some unused piece of legacy functionality. You'll typically only find this out by finding an end user too - noone higher up wants to admit they dont have a clue what that mystery button does.
Admin
Have you tried asking the doc team, training team or customer service team if they have any overview documents or training materials that can give you some context?
A good doc team should know the application inside-out at a conceptual level (surprisingly few companies seem to have good doc team, but that's a separate issue).
A lot of software departments just throw new hires in at the deep end, but that doesn't mean the information isn't out there; as long as you're not fixated on your own team and command chain being your entire world.
Admin
By claiming wisdom you make it very clear you don't have much.
Admin
I'm consulting for a pharmacy near the top of the Fortune 500 and I'm having the opposite problem. Getting close to two months here (plus six weeks training before the client site) and I haven't really written a single line of code yet. One or two test scripts, but that's all. Been just learning about the system the entire time.
Of course, part of that is due to the fact that, on a good day, I'll be able to get a one hour session in with someone and maybe read some documentation...I exhausted the independent training plan long ago though, and spent a while trying to find other documentation and looking at scripts and such, but at this point a large part of my day is spent reading Slashdot and TDWTF...
Admin
You need a big flow diagram fairly high level, a pointer in each box to the documentation store and experts on each area.
Look at the flowchart, pick a box, read the documentation, talk to the experts. Aim to get your name in a few boxes!
Or you can just say its far too complex and develop mediocre code or provide bad support.
I have seen both types of organisation, the second one is more common and painful.
Admin
Expect to learn un-systematically.
Make a personal copy of the code (or version control branch) for your own playground.
Comment the hell out of the code - WHY, not what. Constantly modify same as your understanding increases.
Break code on purpose to see how behavior changes.
Make UML-correct class diagrams, sequence diagrams; Database entity diagrams, etc. Use these as props for questioning your co-workers.
Keep code criticism objective and professional. NEVER say "Who wrote this code!?"... out loud. Never.
Learn the details of how they did the "grunt work" that all apps have - populating screens, business objects, database fetching; "layer interfacing" I guess you could say. Look for patterns - of the personal coding kind vis-a-vis formal design patterns. Soon this "white noise" will fade, and the business-relevant stuff will be easier to see and learn.
Schedule lots of time to sit with your customers using the system. Be sensitive of their workload & time constraints; don't be asking lot of questions when they really need to get work done.
Admin
WTF? Is being on the pointy end of a downsizing, for example, any better because the boss is a nice guy? Do you think they started the business just so they could hire you? Only 1 person can get promoted, folks get fired sometimes no matter how much the boss doesn't want to. Very hard decisions have to be made all the time. I sure don't want it to be easy for them because I'm a slacker.
Admin
This doesn't just happen at large companies where there are business analysts, etc. all doing their part. Sometimes there is just one or two other developers/IT staff that know everything. When they are out on vacation or sick and you're expected to hold everything together, good luck. The best skill I've learned is to take everything in stride and try to keep emotion in check. No matter how invested your are, it is just a job, although perhaps lives and more are on the line, but you just do what you can. Try not to think about it too much when you leave work for the day.
Admin
This is the kind of thing we're looking at fixing in our company right now.
Taking the minimal approach, our team spent a couple weeks writing up "how our system works", "what new hires need to know", "how to keep your system running" etc. in One Note. Shared One Notes are a nice alternative to wikis as there is no learning curve at all, you can embed images, files, etc.
Actually setting up our system... we gave up on that years ago. Thank god for VMWare player. We just keep a VM updated (sorta) so that new hires start with a working system.
Admin
From my experience, as a software developer, you're expected to be an "expert" (after all, you automate their business). Managers recognize your time is valuable and don't want to waste it training you in something you may already understand (or understand well enough that the details don't really matter). However the programming staff should be willing to show you the ropes and walk you through some things.
If you like the company, people, projects, etc. well enough to stay, then my advice would be to give it time. 12 years ago I started working on a project and a team environment that sound similar to yours. I started out just writing code (2 maybe 3 years), then I got tired of not understanding the benefit of what I was doing. For my own satisfaction I needed to know that what I did matters. Since I knew most of the technical ins and outs by then I made a point of asking questions about "the business" and how the requirements satisified their business problems. If nobody has ever asked those types of questions before expect some push back (but I imagine that most of the stuff we see here is from programmers that "just code") as it's a cultural change that you're driving toward. Eventually people will get why you ask those types of questions when you start identifying easier, cheaper ways of doing things without spending thousands of dollars on a customized software solution. You will be a hero to the company, a well respected software engineer and you will learn the business, but it takes time.
For me it took 3-4 years to learn most of the aspects of the business that my software directly effects and I say most because business constantly changes. I've got the big picture and a lot detail in how processes work, but I have learned that I have to be adaptable to the ever changing "business"... There will always be more to learn.
Admin
Hi, I happened to start a new job a few month ago. I work for a company that sells electricity and owns a few small grids. On my first day working there the migration of all the customers to a new system was nearly completed one just had to press a few buttons. I did not know anything about the business yet. But I took the small task to export the contacts to a format readable to the new system. I was able to use any tools I needed which was a big advantage and somehow learned to know the old system a bit. The more tasks like that and now I know a bit about the processes in that business. Just show you're interested in the big system and learn it in small steps. You might eventually get the big picture but it does not matter if you get it as long as you can do some useful thing in the system.
Admin
Wow, this needs to be recorded in annuls of developer lore. Every time you think you got it whipped something else jumps out and the project blossoms new requirements.
Admin
As a young man that was my main talent, shedding the workday. Trying to get it back....important.
Admin
I second the suggestions to take notes; but don't use a text file or other flat format. Use OneNote or a wiki (it's fairly easy to set up a local/personal MoinMoin wiki, for example). (I would not recommend using a remotely hosted note-taking service such as EverNote because you'll likely want to take notes about source and other information considered corporate confidential and they'd probably not be appreciative of it being stored on servers outside the company, no matter how secure they may be.) Personally I really like OneNote for it's instant search capabilities (if I could find an open source equivalent I'd use it), and it's standard with Office 2010. Ideally you can share the wiki/OneNote with other developers, depending on local policies; even if not, even a local one will be useful for you.
If you end up creating tools useful for you but that management doesn't want added to any official repository, create your own local repository with git etc. (and if you can, back it up to a share that is backed up by IT, since it's still work product). I have a number of Python tools I've created and use regularly that increase my efficiency. If you find yourself repeating something, you can probably automate it - and should, if you'd save time by it.
I would also recommend the short O'Reilly book Code Simplicity; it defines a lot of important and valuable principles. Source code in the real world, of course, laughs in the face of principles of software architecture, but perhaps you can at least not add to the crap.
Admin
Admin
Reading through all the comments is fascinating and depressing at the same time.
I've worked in several dev roles and for the last 4 years as head of development/infrastructure. It's a smallish team but the codebase is mature. Everyone works from home, and from different locations around the world. I have been involved in all the interviews/recruitment and all that actually matters is whether the person would enjoy working with the company.
One of the only requirements I insist on (you can use any OS,IDE etc) is to feel free to ask me as many questions about the business/code/networks etc whenever you're uncertain or simply intrigued. I will always make time to answer.
What I've found is that everyone on the team has a similar attitude. Whether it's because I'm "leading by example" or simply lucky, the point is that that's how it should be and I would not accept a job where that wasn't the case.
Nothing is more important than the people you are working with and if they can't be helpful then it's probably not worth staying there. Remember that you're deciding which group of people you're prepared to spend most of your waking life working alongside.
Admin
Bob the new riveter has just arrived on the job. He was told by his supervisor to put 4 mini-mushrooms on every engine at so-and-so location. The problem is, Bob has no idea what a "mini-mushroom" is (let's pretend it's a .5" rivet), and no one will tell him. He's just expected to figure it out on his own.
That's how I understood S.N.'s situation, and I think it's unforgivable. If your company uses jargon, you need to EXPLAIN it to the new people.
Admin
Alex, it hasn't changed much since then. I just spent five weeks at a bank in their loan retention department doing nothing. It took two weeks just to get my dev environment set up. I was assured by a friend who'd worked there for many years that no one individual would be able to affect changes. The bank knew they needed to fix their processes to become more efficient. They were in the first year of a three year plan to accomplish that.
I ran.
Admin
Admin
Respectfully, I'm an IT consultant in the software arena and would like to ask you a question. I was wondering if anyone had done any research/article on buying mathematical algorithms vs. programming them yourself? Especially for complicated mathematical subroutines, is it cost effective to subscribe to an algorithm library (like www.nag.com) for about $3000 per year, or let your programmers do all the work? Have you ever offered an opinion on this subject? If any of your readers have any experience buying an algorithm vs. programming, I'd appreciate hearing about it. Thanks, Steve Chastain [email protected]
Admin
One job I waited 3 weeks before someone got me something to do. Most have at least 1 person that knows it all and doesn't share. In my case I fixed the grid so I could select a row, what I didn't know was that my boss had told people in emails that there was noway to do it.
Perform your job well and learn to love looking at 4 cube walls for the next 30 years. If your lucky you cube mates will be nice but don't count on it.
Admin
Too long; still didn't read.
Filed under: DIDN'T READ LOL, lol
Admin
Then you took an arrow in the knee?
Admin
This guy must be working in the same company I do!
Admin
Don't dispair, it takes awhile (min. 1 year) to start to get comfortable with large systems. One piece of advice however- if you find yourself working with a moderately pleasing to the eye Russian/Azerbijani woman who turns out to be the devil incarnate, follow Christopher's Cross' advice and Ride Like The Wind outta there!
Admin
+2 Assignment or Objective driven with 'what is the next step', best advice. (and keep a written journal).
Admin
+2 Assignment or Objective driven with 'what is the next step', best advice. (and keep a written journal).
Admin
I'm the CTO of a small startup tech company, and even I can know this pain. My advice is that you SHOULDN'T try to understand everything. I practice this even at my current company. There's so many facets to the market we're trying to reach that I have to choose the information that's most important to pass down to my team, rather than make room for filling them in on everything. Focus on the information most important to creating the most output, not in trying to fully understand the entire picture.
Rocket science is hard, but understanding what rockets do is easy. And landing on the moon is much easier when you let everyone else do their job, and you focus on yours.
Admin
Whether or not you believe in God, read this message!
Throughout time, we can see how we have been strategically conditioned coming to this point where we are on the verge of a cashless society. Did you know that the Bible foretold of this event almost 2,000 years ago?
In the book of Revelation 13:16-18, we will read,
"He (the false prophet who deceives many by his miracles--Revelation 19:20) causes all, both small and great, rich and poor, free and slave, to receive a mark on their right hand or on their foreheads, and that no one may buy or sell except one who has the mark or the name of the beast, or the number of his name.
Here is wisdom. Let him who has understanding calculate the number of the beast, for it is the number of a man: His number is 666."
Speaking to the last generation, this could only be speaking of a cashless society. Why? Revelation 13:17 tells us that we cannot buy or sell unless we receive the mark of the beast. If physical money was still in use, we could buy or sell with one another without receiving the mark. This would contradict scripture that states we need the mark to buy or sell!
These verses could not be referring to something purely spiritual as scripture references two physical locations (our right hand or forehead) stating the mark will be on one "OR" the other. If this mark was purely spiritual, it would indicate both places, or one--not one OR the other!
This is where it really starts to come together. It is amazing how accurate the Bible is concerning the implantable RFID microchip. These are notes from someone named Carl Sanders who worked with a team of engineers to help develop this RFID chip:
"Carl Sanders sat in seventeen New World Order meetings with heads-of-state officials such as Henry Kissinger and Bob Gates of the C.I.A. to discuss plans on how to bring about this one-world system. The government commissioned Carl Sanders to design a microchip for identifying and controlling the peoples of the world—a microchip that co